This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Goodmorning TI Community,
Today I write to You because of a strange problem with some elecrtonic board on which there is the MPS430G2402 processor.
After some work cycles the processor stops working well and gets lost.
The origin of this particular behaviour is that unexpectedly the location of the RESET vector reprograms itself with an undefined address
so that the processor doesn't know anymore where is the start point of the program.
The firmware (written in assembly) has been tried and tested for many years and every machine works very well with it.
This is the first time that something like this happens and I don't know why.
Which are the possible reasons?
I also have another doubt/question: the flash of MSP430 micro-processor is protected by accidental writing, isn't it?
So, how is it possible that the reset vector's original address gets lost and auto re-programmed with an undefined value?
You need to know that in this application I only access to the Info Memory, which contains the A to D segments, and I don't write on the Flash Memory.
I hope someone could help me to resolve this strange problem.
Thank you for the attention.
Kind Regards,
Luigi Quaglia.
Hi Ryan,
yes, to answer to your first question the RESET vector is the only one whose locatiom has been overwritten.
I use the "debug without downloading" tool available in the IAR development environment and I notice this problem.
As I said in the previous post, the firmware has been tried and tested for many years and, as it always works perfectly, I haven't made any changes to it.
At the moment the issue occurs in 7 devices (on 50 total), the first I programmed.
I think it is very strange that the processor of these devices has worked well until now and suddenly it stops, even though most of the machines has worked for some months only!
Is it possible that a voltage spike, both in programming or work period, caused the overwrite of the RESET vector only?
The firmware on the processor was debugged without any external power supply during the first programming period, using only the MSP FET emunlation Tool.
Could it be the cause of this "latching" phenomenon?
Thank you for your answer.
Regards,
Luigi
Good morning Ryan,
thank you very much again for your answer.
The power supply is very well filtered so I don't think the machine has experienced any voltage spike during the working period.
The devices has MSP430G2402 processor on board and anything, also in the design of the circuit, has been changed.
I only have the doubt that programming the device without external power supply but only with the emulator voltage can enable this strange latching process of the RESET vector address.
Let's see what the Quality Team have to say about this situation!
Regards,
Luigi
Hi Walther!
thank you for your answer and your questions about the problem.
1. The frequency is set at the maximum possible internal oscillator value: 16 Mhz, while the voltage is 3,3 V.
2. I have a function in the code that reads and writes the info memory. Exept of this the FLASH memory is only read in some particular location in the code.
3. Yes, only 7 devices on 50 shows this issue and, yes again, it is always the same: the RESET vector isn't located to its specific address.
One important thing to highlight is that the processor has worked well for some months, then suddenly happens this strange fact.
Thank you also for the link to the App Note.. I'll read it!
Kind Regards,
Luigi
Hi Luigi,
thanks for answering the questions. You operate the device at 3.3V at 16 MHz right. This means you operate on the border of the specification as you can see below.
On the top you also use flash programming which is causing high peak currents. Therefore I really have to ask:
Are you sure that you will not violate the 3.3V spec with 16 MHz during whole operation (means temperature, all kind of code execution).
Normally LDO does not react very quick on short spikes which might cause problems.
So can you reproduce the behavior? If yes please increase DVCC or reduce frequency to see if it disappears.
Hi Luigi,
I understand your concerns but again if you operate at 3.25V at 16 MHz you will violate the specification also keeping in mind the DCO drift over temperatuer.
But to better understand what's going wrong:
Are there any signficant differences to the applications your company produced before?
Do peform DCO frequency switching in your application? If yes are all the existing ERRATAs considered?
Best regards,
Dietmar
**Attention** This is a public forum