TMS320F28335: What can generate a XRS* reset signal (in addition to the watchdog)?

Sorry I also forgot to indicate that I am using the fast libray : rts2800_fpu32_fast_supplement.lib for div and atan2
When I remove this library I do not have the "reset". But not sure that if it is the real explanation.
I tried to rebuild the library with my current compiler version but does not solve the issue.
I also try to do nothing inside the function (just a LRET) but doe snot solve the issue.
When I am adding some NOP before calling the "div" operation I do not have the "reset" but not sure that if it is the real explanation.
Hope that it may help you to understand my problem.

Thanks,
Mathieu

Hi Mathieu,

On this device, WD is only source which can toggle the XRSn (apart from power on reset). You can check the WDFLAG bit in WDCR register to know if WD has caused the reset.  It may be that some run away code (due to stack pointer corruption) is writing to WDCR register and causing the reset (writing a value other than 'b101 in WDCHK field of WDCR register causes immediate reset).  You could set a watch point in CCS to halt the CPU if there is any write to WDCR register.

Detail on how to set the watchpoint can be found here.

Regards,

Vivek Singh

Thanks Vivek for your quick answer
I added the breakpoint as indicated
But when the MCU halt is on:
LB _c_int00 of the file : DSP2833x_CodeStartBranch.asm
?
Do you have any idea?

One additional information, when I set the breakpoint when MCU is writting 0x7025, the MCU halts on 0x3FF866 that looks like to be the  Boot ROM. See attached file:

Thanks in advance

Sorry could not attached the file..
At the address, 0x3FF866 I can see:
MOVB @0x25, #0xaa
Do not know if it may help. But looks like close to 0x7025

Sorry for all this post.. just to try to find the solution fatser..
But just to say that I set a breakpoint at the adress: 0x3FF861 and the MCU halt.
So looks like that the boot rom is called ? do you confirm ?

Mathieu,

Can you check the EMUBOOT setting. Basically the value written at address 0xD00. When CCS is connected, device boots as per emulation boot mode which depends on value written at address location 0xD00. Please refer the device TRM to know more about emulation boot mode.

Regards,
Vivek Singh

Also please enable the breakpoint after code jumps to your application. Look like you are enabling it during bootrom execution itself which will not work because BOOTROM does writes to address hence set the breakpoint after entering the main().

Regards,
Vivek Singh

Hello,
Regarding: "enable the breakpoint after code jumps to your application"
I confirm that in my previous test I only enabled the Hardware watchpoint and Breakpoint after being into my application.
I could see some "printf display" then the MCU halts in the breakpoint location.
Thanks
Mathieu

And that breakpoint is in BOOTROM. Correct?
Also when breakpoint is hit, you see the XRSn pin going low. Correct?

Vivek Singh

Thanks Vivek for your quick support.

Indeed when I lauched my application I could see:
1) some "printf" results from first iterations of my processing (loop0, 1,2,3 and 4)
2) then (after 4 or 5 seconds) the MCU halts at @ 0x3FF85E (where I set the hw breakpoint in the BOOTROM)
and I can see on the scope a reset (XRSn pin goes low during around 113 ms)

Note:
If I keep running my test application in loop I can see several reset signal and my test is resting at different time because I can see my printf iterations loop that may reach higher values.. but after a variable time I have a reset.

Do you know what is happening ?

Thanks,
Mathieu

Hello Vivek, thanks for the support.

Indeed when I am executing my test application I have the following events:
1) I can see some first iterations printf
2) Then, the MCU halts at the address 0x3FF85E that is BOOTROM
on the scope I can see XRSn pin going to low during around 114 ms

If I do not see breakpoints, i can see my test application that is reseting in loop but at different time because my iterations printf indicator does not reach always the same value.

I was suspecting my hardware so I changed of JTAG and F28335 board but I have still the problem.

Hope it helps for helping me to troubleshooting my current big issue.

Regards,
Mathieu

Mathieu, We need to find out why code is jumping to BOOTROM. It may be due to stack corruption. After entry to main(), can you set a breakpoint at BOOTROM entry point and another breakpoint at 0x3FF85E and see if CPU halts at 0x3FF85E before halting at entry point? If it does then that means for some reason (one thing is stack corruption) execution jumps to BOOTROM.

Regards,

Vivek Singh

Vivek,

Again thanks for your support.. I know that it is difficult to trouble shooting in remote..

In the Debug Configuration pannel of CCS, I have to keep selected the option "Enable CO function use".

Indeed in my application I am using printf/scanf.

So as this feature is activated, I think it is taking one HW breakpoint so unfortunately I cannot do what you are asking (setting 2 HW breakpoints).

If I unselect this feature, when my test is executing, when I am reading my input test data file, the:

" fscanf(fp_datainput,"%f",&ptr_local_input_data[i].dat[0])"

is returning enf of file, so my test code is not called.

However if I force the execution (not checking the scanf end of file), I am also reproducing the issue (reset) that is actually a good thing to understand the issue.

So finally as aksed, after being in the main(), I set the two following breakpoints:

1) 0x3FF9CE : that I think it is the BOOTROM entry point, could you confirm ?

2) 0x3FF85E

I can see also that my test is running up to the iteration 5 as usual (with some global variable displayed in the Expressions tab of CCS).

And the MCU halts first in : 0x3FF9CE .

Then I tried to dispay the stack but this one is already fill with values equal to zero.

I dumped the F28335 memory from 0x0 to 0x10000 , for a start reset/start done with CCS and the current memory content after the issue (with MCU halt at @ 0x3FF9CE).

What do you think ?

dump_memory_after_issue_ROMentry.datdump_memory_after_resete_start_with_ccs.dat

Mathieu, if you see all the stack is getting initialized with zero when it halts at the BOOTROM entry point then most likely your code has written that value and that has caused a WD reset. You can check the WDFLAG flag bit in WDCR register to confirm if reset was caused due to watchdog. Is it possible to not enable the "Enable CO function use" and run the code and see if this issue does not occur ?

Regards,
Vivek Singh

Thanks Vivek

Do you mean: Enable CIO ?

In addition, sorry I did not indicate to you but when setting a GPIO as output I do not have any problem.

We do not still understand why.

This GPIO is used to manage a circuit that generates our external clock.

I will let you know.

Mathieu, were you able to get any further update on this?