Nick,
Thanks for the additional details. I’d thought a bootloader must be involved, but it wasn’t clear to me from your first post.
I’m not familiar with this bootloader and how it starts the program. My guess is that there is something done in the GEL file that is not done in the case where the bootloader is used. If it was some drastic difference it seems the program would not run at all. A subtle difference will be much harder to trace down. But it could be something such as setting wait states (this is just a wild guess) that could cause intermittent failures.
For very high levels of optimizations it isn’t uncommon to have odd differences in program execution. But basic optimizations shouldn’t cause issues. Unless there is some sketchy timing in the first place that is vulnerable.
Can you attach to the CPUs when the program has already booted from SD? If so, can you check critical timing settings (like for DDR), especially those setup by the GEL file, to see if there are differences from execution in CCS?
Another thing to maybe try… can you remove the GEL file from the project and then start the bootloader in CCS and let it boot as if from SD? And then maybe use the GEL file, and similarly run the bootloader from within CCS to see what is different when the program gets to main(), for example? And maybe dump memory contents of key regions in each case to look for differences that don’t make sense?
Since I don’t know this product I’m just guessing here. Hopefully some of this helps. Or, someone familiar with the BBB on the forum can provide some more concrete suggestions…
Scott
↧
Forum Post: RE: SYS/BIOS application instability
↧