Hello everyone,
today I'm asking for hints on a tricky problem. We have a firmware that uses RTX-Kernel running on a NXP LPC2368. Now the device that the firmware is written for should get a new lc display. My honest mission is to change the firmware in order to use the new display.
I've spent some weeks this year to do so and some time I've had the problem that the controller resets short time after start and again and again...
Everytime this behaviour occured I have deleted one or more obsolete variables (mostly global) or functions. In most cases I solved the problem by searching other obsolete variables and deleting them from source code - try and error. That is really time-killing.
While testing the firmware on wednesday, I tried to make the adopted and modified routine for writing data to display RAM a little faster. I moved an global unsigned int to the function and changed it to static unsigned char because the value it has to carry is 0x0D at a maximum.
After flashing the firmware in the controller, the controller hung at a random short time.
Yesterday I was trying to solve the problem with hanging firmware on random time and found the problem when no task is running: OS calls os_idle_demon() and was not able to return from it. I found a solution in world wide web: Creating an empty low priority task without using any os_wait functions that prevents the OS from calling the idle task. (It has something to do with incorrect interrupt states on retunring from idle task.)
Today I further tried to make the display writing function faster and changed two unsigned char inside the function from static to non-static. After flashing this firmware the controller resets again and again. I will now try to find out why the controller behaves this way.
What I found out is, that no watchdog is enabled by user (is it part of the OS?). The os_stk_overflow an os_idle_demon are not called from OS. I debug the firmware using ULINK2.
Any ideas where to search the problem for?
Best regards
Hi Robert,
I don't think anyone has asked yet but what is the source of the reset?
In other words what is the value of the RSID after the reset?
M
I think Marc Crandall is right. And maybe it is not a Reset, it just looks like a Reset.
Hi Robert Suess,
Did you implement any of the
Undef_Handler SWI_Handler PAbt_Handler DAbt_Handler
or some kind of software reset functionality?
I see, thank you for all the answers.
@S Steve: Ok, thank you for sharing your refreshing ideas. :) I was not quite sure if you where trolling around.
The general consensus is that there are no serious bugs in the linker.
Should I go with the flow or should I make my own experiences, what do you think?
@Per: Thank you for enlighten me about S(tunned) Steve. ;)
@Marc: Welcome to my thread and thank you very much for your input! I will try to enforce the reset again and if successful, I will check the value of the RSID after the reset like you suggested.
To answer Johns question: It is very difficult for me to find all pieces of the puzzle since I not wrote the firmware on my own. It is a crackbrained mix of a very old firmware written for a 8bit controller, a non actual RTX USBCDC example project written for 'Keil MCB2300' and a patchwork of code snippets to make the firmware behave like it should. And no comments are in the code. Do not get me wrong, it is a great achievement that the firmware runs like it is expected to do. But for me as programmer it is hard to find errors if they occur now.
The information I can give this moment is, if it helps to clarify your question John:
; Exception Vectors ; Mapped to Address 0. ; Absolute addressing mode must be used. ; Dummy Handlers are implemented as infinite loops which can be modified. CDCVectors LDR PC, Reset_Addr LDR PC, Undef_Addr LDR PC, SWI_Addr LDR PC, PAbt_Addr LDR PC, DAbt_Addr NOP ; Reserved Vector ; LDR PC, IRQ_Addr LDR PC, [PC, #-0x0120] ; Vector from VicVectAddr LDR PC, FIQ_Addr Reset_Addr DCD Reset_Handler Undef_Addr DCD Reset_Handler;Undef_Handler SWI_Addr DCD SWI_Handler PAbt_Addr DCD Reset_Handler;PAbt_Handler DAbt_Addr DCD Reset_Handler ;DAbt_Handler DCD 0 ; Reserved Address IRQ_Addr DCD IRQ_Handler FIQ_Addr DCD FIQ_Handler IMPORT SWI_Handler EXTERN DAbt_Handler ; RoS| 29.11.11: for RT-Agent (http://www.keil.com/support/man/docs/ulink2/ulink2_ra_modifying_startup.htm) Undef_Handler B Undef_Handler ;SWI_Handler B SWI_Handler PAbt_Handler B PAbt_Handler ;DAbt_Handler B DAbt_Handler ; RoS| 29.11.11: for RT-Agent IRQ_Handler B IRQ_Handler FIQ_Handler B FIQ_Handler ; Reset Handler EXPORT Reset_Handler Reset_Handler
This is part of the modified startup file lpc2300.s. Hope this helps.
It's a pretty safe bet to say that there are no serious bugs (and probably very few minor ones).
There is one person who claimed there was a dealy bug in the linker recently. However the evidence given was stunningly flawed.
I see.
I can not make the firmware reset permanently at startup today. I will try further on monday.
Thanks again for all hints and comments!
I only reply to technical statements made by the stunned among us. Now that he finally made one (!) he will get an answer:
First of, the linker, at least the one provided with MDK 4.14 is not perfect. Do you work with CM0 devices (LPC1114)? If you do, you might have encountered a failure to link with less that 0x2000 bytes of RAM available in the scatter file - fixed _ONLY_ by changing 0x2000 to 0x5000, linking, and then going back to the original setting (0x2000), which then links as well (!).
Now that he finally made one (!) he will get an answer:
Are you trying to take the proverbial? I replied to your mis-interpretation with an appropriate and valid question in:
http://www.keil.com/forum/19955/
Look carefully at how you answered it.
Professional ... I think not.
@Robert
Your fault handlers are simple while(1)s. Maybe to proceed you could implement more informative handlers to see if you can gather more information about where this fault (if any) is coming from.
Actually I didn't examine your source properly. It looks like all of your handlers are pointing to the Reset handler.
For starters put the while(1)'s back and see if you get stuck in one of these handlers.
Like so:
; Exception Vectors ; Mapped to Address 0. ; Absolute addressing mode must be used. ; Dummy Handlers are implemented as infinite loops which can be modified. CDCVectors LDR PC, Reset_Addr LDR PC, Undef_Addr LDR PC, SWI_Addr LDR PC, PAbt_Addr LDR PC, DAbt_Addr NOP ; Reserved Vector ; LDR PC, IRQ_Addr LDR PC, [PC, #-0x0120] ; Vector from VicVectAddr LDR PC, FIQ_Addr Reset_Addr DCD Reset_Handler Undef_Addr DCD Undef_Handler SWI_Addr DCD SWI_Handler PAbt_Addr DCD PAbt_Handler DAbt_Addr DCD DAbt_Handler DCD 0 ; Reserved Address IRQ_Addr DCD IRQ_Handler FIQ_Addr DCD FIQ_Handler IMPORT SWI_Handler EXTERN DAbt_Handler ; RoS| 29.11.11: for RT-Agent (http://www.keil.com/support/man/docs/ulink2/ulink2_ra_modifying_startup.htm) Undef_Handler B Undef_Handler ;SWI_Handler B SWI_Handler PAbt_Handler B PAbt_Handler DAbt_Handler B DAbt_Handler ; RoS| 29.11.11: for RT-Agent IRQ_Handler B IRQ_Handler FIQ_Handler B FIQ_Handler ; Reset Handler EXPORT Reset_Handler Reset_Handler
Never ever jump to the reset vector/start address.
The processor has not been properly reset, and there is a big likelyhood that the startup code and application code makes assumptions about current processor state that isn't true.
Most processors can make use of an internal watchdog handler to force a real reset.
Some processors have an internal register bit that can be written to to force a reset.
For most other processors, the hw designer should add external circuitry giving the processor an ability to force-reset itself.
Note that a real reset doesn't only put known content into all different registers. It also resets state machines inside the processor - often resetting state information not possible to reach using software. So a jump to the reset vector could result in a processor with a hung UART, interrupt controller or similar, and no way to get the chip back into working order again with less than a power cycle by the user.
I agree. (@Per - for many chips technically I think you could write a Reset Handler that properly resets / re initializes all your peripherals and the CPU properly but certainly not common or in my opinion good practice. But as you point out I may be wrong in that thinking)
I once had found a website that had excellent examples of handlers (for debug purposes) for ARM7 and Cortex-M3 does anyone have any good links with any good examples?
I have seen one too, and later saw links to it on this forum.
A bit of Google skills should be able to pick up on it - was showing code to walk the exception stack.
Not applicable to ARM7 but for future reference here is a good one for Cortex M3/0
support.code-red-tech.com/.../DebugHardFault
Thank you very much Per and Marc again for all your answers to make me moving in the right direction.
Actually I read 'The Insider's Guide To The NXP LPC 2300/2400 Based Microcontrollers'. I have the feeling that I should have done this earlier, but I did not know anything of the existence of such a document.
I will report here if I can make the reset happen again and I will try to find the handler that leads to the reset.
Good morning everyone.
Things appear a little bit clearer to me now. I am still reading the guide. If I understand all your latest posts right and review the startup code of our firmware, I realize that in our firmware all protection exceptions (Undef, PAbt, DAbt) lead to a reset of the device.
That means if any of these exceptions occurs, the firmware forces a reset. Again and again, if the exceptions source is an error in the source code of our firmware. Because of this, I am not able to find any error if the firmware resets on every exception...
Am I right so far?
And additionally: The included RealTime-Agent is not able to work like it should, because of this line:
DAbt_Addr DCD Reset_Handler ;DAbt_Handler
Right?