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.

Unhandled and unknown data abort exception after repeteadly pressing RST button in TMDX570LS31USB

Other Parts Discussed in Thread: UNIFLASH, HALCOGEN

Hi, we are using Halcogen-generated code for the TMDX570LS31USB and a simple application that turns on a led. If we quickly press the RST button around 5-10 times, a data abort exception will be raised. Looking at the assembly we noticed the instruction that raised the exception is a str.

The problem is that if we try to reset the system by writing to the SYSECR register, we correctly jump to the reset handler but as soon as we hit that str the exception will be raised again. The weird thing is, it seems to always be the same str that causes the issue. Sometimes even pressing PORRST won't work, and we'll have to manually power cycle the board to get it to work again. Even weirder, re-flashing the board using CCS Uniflash won't make the exception go away.

We stepped through the data abort handler code generated by Halcogen (the file is called dabort.S) and we noticed our particular case isn't contemplated (it ends up branching to custom_dabort). The ESM and TCRAM status registers are all 0.

We tried this with several programs and it's always a str that causes the problem (the target address of the str varies from program to program). Notice, however, that without repeatedly pressing the RST button the programs work fine.

We checked the DFSR Register of the CPU and its value signaled a Memory Access synchronous parity error.

Any help on this will be appreciated.

  • Hi Marcos,

    I know that you mentioned that it doesn't seem to be code dependent, but can you post a zip of one of the projects that seem to be having an issue so I can try and recreate your issue in our lab?
  • Hi, thanks for answering.

    Here I attach the zip of a proyect, with the Halcogen sources, and a main that should turn on leds. This in particular is for gcc but we tried with code for CCS and noted the same problem. Thanks!4010.Tiny.zip

  • Hi Marcos,

    Can you let me know which device revision you have on your board? The rev letter is the letter just prior to ZWT on the device part marking. i.e., TMS570LS3137XZWTQQ1 where 'X' will denote the device revision.

    The reason I ask is there are a couple of known issue with nRST on earlier revisions of silicon. See Advisories DEVICE#152, DEVICE#153, and DEVICE#156 of spnz181A for silicon revision A and SYS#111 in spnz193d for silicon Rev.B.

    On a side note, I was not able to recreate the issue on my hardware. I am using silicon revision A, but this is not surprising since the issues can be very device dependent.

    Let me know which rev you have and we'll figure out where to go from there.
  • Hi, we have three boards with revision A. And we see this problem in all of them.
    Perhaps you aren't pressing the rst button fast enough.
  • Hi Marcos,

    If I may ask, what are your requirements for nRST? i.e., is there something specific to your project that requires you to test the board in this manner and that requires robust operation with multiple, quick, nRST assertions? Also, please look for a request to start a private conversation on this topic so we can work through the issues to a resolution.
  • Hi,

    We are also seeing the same behavior when the device resets by Watchdog: If we let the WD reset the board many times, it will eventually hang and not starting again until a PORRST is pressed. This seems a more important issue than the reset button's issue since the WD must be working necessarily for our project.

  • Marcos,

    Can you please confirm that you are working with rev A of the silicon still? As Chuck mentioned earlier, there are several issues related to the timing of the system reset that can cause the CPU to halt code execution. These issues have been addressed in later revisions of the LS3137 MCUs and you should not see these issues.

    Regards,
    Sunil
  • Yes, I'm using revA. I will let you know when I can try a rev C. I just wanted to confirm that this issue is related to the other. Thanks!