- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
A too important number of CC2530 devices fail in the field - the system locks up for some reason. I can't use the usual flow.
After checking all options, it all boils down to generating the code with "Debug information for C-SPY" or not.
I tried disabling optimizations, etc. Strangely enough that option really does the trick.
I checked this by reading the flash contents from a failing device to a hex file which is then reload into the device before each partial flash update where NV memory and internals are protected from being overwritten (flash pages 120 and up (122 and up would in theory suffice)).
As soon as the "Debug information for C-SPY" is enabled, the misbehavior is gone.
At the same time it's a chicken and egg problem - I can't debug in detail when C-SPY is disabled, and the problem is gone when enabling C-SPY. It looks like a Heisenberg principle for embedded software.
Anyway, I would like to continue to automate HEX file generation.
I tried the "Extra Output" tab as well where the tickbox can be checked, but no '...a51' file is generated (the project name has been blanked out). That can not be selected when "With runtime control modules" is enabled, but as the screenshot shows, it still says "Secondary output: (None for the selected format). So it's probably an IDE corner case where the "Extra Output" can be configured even though it isn't really applicable.
The only alternative I see at this time is to program a device interactively, then read back the contents to a hex file, clean up that hex file and use it for programming other devices. That requires several manual interventions: program using the IAR IDE, read back using the Flash Programmer, and pd manually clean up (/eventually create a script for that).
Any other suggestion is welcome.
Extra Output setting:
