Access to the last instruction before a system reset [TMS570LS3137 - SDRAM]

Hi Antoine,


System Exception Status Register (SYSESR) in the SYS module is indicating a value of 0xA008 as shown in your log:
R Sys_SysEsr 0x0000000B 0x0000A008. Since several bits are set I'm not sure the root cause yet. Even the power up reset flag is set. I wonder if you have cleared power up reset flag the first time after you power up as part of your power up reset routine. Please clear all flags in the SySESR first before you start your application. Once you get a reset again we can look at the SYSESR to determine the real root cause. Since the watchdog reset bit is also set currently i tend to think that the reset could be due to watchdog rather than power up.

Hi Charles,

I have added a reset handler that is similar to the HalcoGen one. After clearing flags in the SysEsr, its value is 0x00000008. After the system reset the SysEsr value is still 0x00000008. So the reset may not be due to watchdog.

I attached the dump of registers.

Regards,

Antoine3580.DumpRegistersAfterReset_ResetedFlags.txt

Antoine,

The value 0x8 in SysEsr indicates that there was a External Reset caused by the nRST pin. However, you are writing that the value of SysEsr after clearing is still 0x8, which shouldn't be the case. Please make sure, that you clear all bits in your startup routine to be able to figure out the real root cause.
On the other hand there are only two possibilities left right now. First is that the controller got reset by an external circuit, which is unlikely on the HDK board. The other is, that there was no reset, but that there was another reason that the CPU branched to the reset vector.
Could you please hook an oscilloscope to the nRST pin to monitor it (single shot). The nRST pin is bidirectional and is indicating if a device internal "system" reset happens.

Thanks,
Christian

Antoine,

I loaded your binary (testRtemsWorkStackInSDRAM.out) on my HDK board and it appears to work.

I see the following strings on my serial console:
Hello World 0
Hello World 1
Hello World 2
Hello World 3
Hello World 4
Hello World 5
Hello World 6
Hello World 7
Hello World 8
Hello World 9
Hello World 10
Hello World 11
Hello World 12
Hello World 13
Hello World 14
Hello World 15
Hello World 16
Hello World 17

Also the 8 user LED's are lighting up on after another in a circular way.

So what is what you make think, that there was a reset?

My HDK is revision E with a TMS570LS3137 Rev C on it.

Thanks,
Christian

Hi Christian,

I uploaded the same binary twice. Here is the binary that leads to a system reset. 6180.testRtems.zip

I have patched the function that clears the reset flags. Now SysEsr is equal to 0x0 after clearing and after system reset.

I will checked if RTEMS has an instruction which jump to the reset vector.

Regards,

Antoine

Hi Christian,

I have monitored the nRST pin. When manually pressing the RST button, the nRST signal goes from HIGH to LOW. But when executing my program the nRST signal is always HIGH. So no device internal "system" reset happens.

I have also checked my RTEMS program. I have not seen any jump to the reset vector.

Regards,

Antoine

Antoine,

Just to let you know, this topic isn't forgotten. But I was very busy the last couple of days and I'm out of office next week and thus wont be able to look at it again before the 13th.

Best Regards,
Christian

Antonie,

I meeting got cancelled and I finally found some time to look into this again.

The following call is what's causing your application to branch back to 0 (reset vector):

You see it performs a branch and exchange (bx) with the linker register (LR) being the target and holding 0.

I can't give you an explanation why this is the case, but you should try to debug this function (_CPU_Context_switch_arm).

Best Regards,
Christian

Christian,

Thanks a lot. I have made an hypothesis on a context switch error. With this clue I will be able to investigate on my issue.

Best regards,
Antoine

Hi Antoine,

did you were able to you solve this issue?

Thanks,
Christian

Hi Christian,

I have found the instruction that lead to the issue : 

STR       R3, [R0, #44]

After the previous instruction, the register R3 is equal to 0x00000000. When using breakpoint on the instructions block, R3 is correctly stored at the base address (R0 value) plus an offset of 44 bytes. But when executing the instructions block without breakpoint, R3 is stored at the base address (R0 value) plus an offset of 40 bytes which is the address where the LR register was previously stored.

Instructions block :
MRS       R2, CPSR
STMEA     R0, {R2, R4, R5, R6, R7, R8, R9, R10, R11, R13, R14}
ADD       R3, R0, #48
VDUP.32   D3, R8
MRC       P15, #0, R3, C13, C0, #3
STR       R3, [R0, #44]

I don't understand the reason of this behavior.

Regards,

Antoine

Thanks Christian,

I have a Rev. C silicon. The switch of configuration from NORMAL_OINC_NONSHARED to DEVICE_NONSHAREABLE has resolved my issue.

Best Regards,
Antoine

Antoine,

Good to hear that you were able to solve the issue. Here is a short explanation on what happened or what I think happened, the CPU can perform all sorts of optimizations for read and write operations to Normal type memory, I think it performed a merge with a previous write and thus converted the single write into a burst which we know causes issues on older revision silicon (than D).

Please note that EMIF in general isn't too fast on our Cortex-R4 based Hercules devices. With having it configured to Device or Strongly Ordered type memory performance will even be worse. Thuss please keep in mind that you should see a slight performance boost with the new revision silicon. However, placing Stack into the external memory isn't the good from a performance standpoint as well as from the safety side, as we don't have ECC or Parity on the EMIF.

Best Regards,
Christian