• State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 10 subscribers
  • Views 2342 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Microcontroller is reboot during the flash file system

Saranbabu

Dear team,

We've developed our product for the electrical domain, in our produced we've used LPC2468 microcontroller with ARM7 architecture.  In our product we are using Keil RTX operating system and its flash file system.  We are having the 4MB external NOR flash memory, in that flash file system has ported for store the files.  In our source code, we are not able to see the source code of flash file system, it is in the form of library it seems.  Recently we are facing issue that, microcontroller rebooting during the flash file system, when source invoke the finit() API system is getting reboot.  We are not able to fix this issue because it is in the form of library, so please let us know how to fix this issue? and what would be the reason for reboot during the flash file system?.

Parents
  • 0

    It is hard to give you hints because I don't know your application. When I understand you correctly, you see a reboot of your target system when you call the finit() library function. Does that happen every time? In most applications, finit() is only called once when the application starts. Is this the case in your application as well or do you initialize the Flash filesystem multiple times in your application before you write data to the file system? 

    Since there are no standard ways to perform a reset in an application, our libraries cannot cause a reset. There are only a few possible scenarios:

    • Does your application use any kind of Watchdog timer? If yes, our libraries might need longer than expected and your application misses the time to feed the watchdog timer in time. This might cause a reset.
    • Your application (or maybe our library) might use a non-initialized function pointer and might jump to the reset address and your application would restart without really resetting the peripherals.
    • Your application (or maybe our library) might cause an exception (data abort, program abort, undefined handler). In our standard startup modules, all these exception handlers are endless loops, so your application would just stop doing anything.

    Do you see this issue also in a debug session? If yes, you could track where this issue comes from by setting breakpoints in the startup code or in exception handlers.

Reply
  • 0

    It is hard to give you hints because I don't know your application. When I understand you correctly, you see a reboot of your target system when you call the finit() library function. Does that happen every time? In most applications, finit() is only called once when the application starts. Is this the case in your application as well or do you initialize the Flash filesystem multiple times in your application before you write data to the file system? 

    Since there are no standard ways to perform a reset in an application, our libraries cannot cause a reset. There are only a few possible scenarios:

    • Does your application use any kind of Watchdog timer? If yes, our libraries might need longer than expected and your application misses the time to feed the watchdog timer in time. This might cause a reset.
    • Your application (or maybe our library) might use a non-initialized function pointer and might jump to the reset address and your application would restart without really resetting the peripherals.
    • Your application (or maybe our library) might cause an exception (data abort, program abort, undefined handler). In our standard startup modules, all these exception handlers are endless loops, so your application would just stop doing anything.

    Do you see this issue also in a debug session? If yes, you could track where this issue comes from by setting breakpoints in the startup code or in exception handlers.

Children