Just as background, I’m using and LPCH2148 board, Jim Lynch’s startup and linker files, WinARM as my toolchain, and flashing my programs with OpenOCD.
In my program, I am initializing a character LCD (over a parallel interface) and two nRF24L01’s (both over SPI). I also read a value out of each of the 24L01’s to verify that they were written correctly and write the values to the LCD. When I was testing the software for each device, everything worked fine. I could get both 24L01’s to communicate over SPI at the same time I was writing data to the LCD.
Now that I’ve written a test program to get it all to work together, it seems like after I flash the board, the code doesn’t execute SOMETIMES. When it doesn’t work, the LCD doesn’t initialize, the LED on the board won’t blink (I set it to blink every second in the main while loop). Other times, the LCD won’t work but the LED will blink. It’s almost like I can comment out arbitrary lines, recompile, and program the flash again and it works. It’s totally screwy and I can’t figure out what the deal is.
I don’t think it’s because of my hardware as I’ve tested to make sure I don’t have shorts and the like. Either way, even if I completely disconnect the header board from everything, it still does the exact same thing. I’m coming to the conclusion that 1) I have a bad ARM, 2) I have written bad code, or 3) something is going on with OpenOCD.
As of right now JTAG programming is my only option because I have my LCD set up on the pins that UART0 is on. I haven’t tried using OCDRemote yet, however.
If anybody has seen anything like this, let me know.
Hey,
make sure you’re using the latest version of OpenOCD (SVN revision 62). There were some issues with versions prior to Rev. 61 that could corrupt flash programming, although OpenOCD printed an error msg in these cases, either on the telnet prompt or at the daemon output.
Regards,
Dominic
I’ve been playing with the LPC-2148 header board (only USB and JTAG, right?) recently, using a toolchain on Linux and OpenOCD to burn the flash. It works OK most of the time, but when it doesn’t, it’s never clear why not. One thing to check is P0.14. This is unconnected on the header board (and not pulled up). If the Philips bootstrap loader thinks the pin is low when it starts up, it’ll run the bootstrap instead of whatever is in Flash.
If Olimex makes a new version of that board, it’d be nice to have a pull-up / pull-down jumper so you can control the pin easily. As it is, I have a wire stuck into one of the socket holes and use an alligator clip to ground the pin when I want to go into the bootloader.
Now that I think of it, that may be part of your problem – when you have good code (or at least a valid checksum) in Flash, it seems like flashing new code over it works better if you ground P0.14 before you start. I bet it’s got something to do with interrupts – you probably want to make sure there’s no question about what code runs at reset or if an exception happens.
I had actually wondered about that spacewrench, but assumed it would work anyways. I’m going to wire up a jumper to my perfboard to ensure that the chip doesn’t go into the bootloader. Dominic, I’m also use the new version of OpenOCD I just downloaded. We’ll see how everything goes. Thank you so much guys.
brennen:
I’m going to wire up a jumper to my perfboard to ensure that the chip doesn’t go into the bootloader.
Just to clarify: I think you want it to go into the bootloader if you’re trying to program the Flash memory. So make sure you can ground P0.14 if you’re trying to do that. After you’re happy with the program, pull P0.14 up for normal use.
The problem ended up being OpenOCD. I just installed version 62 and programmed my chip and all is well. Oddly enough, with version 55 I was using before, I never got any type of error message. For ANYONE using OpenOCD, I would recommend you download version 62. Thanks for bringing it to my attention, Dominic.
Maybe I shouldn’t have touted OpenOCD just yet. It certainly could be a compiler thing, but I’m running into a problem with functions taking char* variables (I have a function that prints a C string to an LCD). My source compiles fine, and it seems like as long as the function calls are in the beginning of main(), it works. However, once it goes past that, the functions print nothing.
I have verified this by debugging, and it essentially is showing that the first character of the char* array is null when the program doesn’t work. Considering that these variables are stored in flash program memory, this is what leads me to believe it’s another OpenOCD problem.
Here is some working code:
int main()
{
// Initialize the system
unsigned int count = 0;
char data[2];
int retval = 0;
Initialize();
LCDWriteSTRING("I");
spi1_clear_fifo();
data[0] = 0x00;
data[1] = 0x00;
spi1_send(data, 2, 0);
LCDWriteSTRING("1: ");
while (1)
{
DelayMS(1000);
ToggleLED();
}
}
Both of the LCDWriteSTRING functions fire with the correct parameters in the above code snippet. This gives an output of "I1: ", which is correct.
The next section of code simply adds a while loop after LCDWriteSTRING("1: ") in the previous example. I use this to print out the values in the SPI FIFO (my spi_read () function returns -1 if the FIFO is empty).
int main()
{
// Initialize the system
unsigned int count = 0;
char data[2];
int retval = 0;
Initialize();
LCDWriteSTRING("I");
spi1_clear_fifo();
data[0] = 0x00;
data[1] = 0x00;
spi1_send(data, 2, 0);
LCDWriteSTRING("1: ");
retval = spi1_read();
while(retval != -1)
{
LCDWriteHEX(retval);
LCDWriteCHAR(' ');
retval = spi1_read();
}
while (1)
{
DelayMS(1000);
ToggleLED();
}
}
None of the strings are output from the LCDWriteSTRING functions that worked before - only the output from the LCDWriteHEX and LCDWriteCHAR functions are written. I don’t think it’s a bug in my code because the code that worked in the first example doesn’t work in the second even though it’s executed before the new code.
I think I’m just going to give up on OpenOCD and get a serial to UART converter. 
One last thing - I figured out why it seems the program goes off into never never land. A void function is not returning. The debugger view essentially has it continuing on down my main.c file into the stub interrupt functions at the bottom of the file. This was the same problem I was having with OpenOCD version 55. It doesn’t happen as often with version 62, but it’s still happening. Definitely switching to UART to serial converter now.