I'm assuming there's nothing to prevent errant code from overwriting other code or data memory, even that assigned to stuff like HAL and startup code?
Is this true? because I've had some very odd problems today, they've gone now but I'm not sure if they were due to some corruption caused during execution of test code.
A recurring problem is resetting the Nucleo when I suspect corruption is present. This simply causes the already installed code to start again and so corrupt again. So by the time I've started the app under debug to see "what's happening" the problem, corruption, has already done the damage.
The only way I've found to avoid this is to put say a 30 seconds delay at the start of the app, then I can repower the board and promptly attach the debugger to it, that way the code restarts but never gets running, so when the 30 seconds times out I am in control of the system before any corruption can take place, of course I don't need to wait for the 30 seconds, I can just do a "Set Next Statement" in Visual Studio, but you get the idea.
It's rather hard to say whether the odd issues I saw were due to:
There's no way to reset the nRF24 other than cycling it's power and adding that ability to the control software seems like a lot to ask, why they didn't expose a hard reset pin is a mystery to me.
How is this handled in professional projects?
Is this true? because I've had some very odd problems today, they've gone now but I'm not sure if they were due to some corruption caused during execution of test code.
A recurring problem is resetting the Nucleo when I suspect corruption is present. This simply causes the already installed code to start again and so corrupt again. So by the time I've started the app under debug to see "what's happening" the problem, corruption, has already done the damage.
The only way I've found to avoid this is to put say a 30 seconds delay at the start of the app, then I can repower the board and promptly attach the debugger to it, that way the code restarts but never gets running, so when the 30 seconds times out I am in control of the system before any corruption can take place, of course I don't need to wait for the 30 seconds, I can just do a "Set Next Statement" in Visual Studio, but you get the idea.
It's rather hard to say whether the odd issues I saw were due to:
- A bug in the code I was testing.
- Corruption to the code or memory (yes, I know, that's a bug too!)
- The nRF24 device itself, getting into a bad state.
There's no way to reset the nRF24 other than cycling it's power and adding that ability to the control software seems like a lot to ask, why they didn't expose a hard reset pin is a mystery to me.
How is this handled in professional projects?
Last edited: