• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 1142 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28377D: Reset

Diego Bellachioma
Intellectual 500 points
Other Parts Discussed in Thread: TPS62420

Hi Vamsi.

I notice, since yesterday, a strange reset event about CPU1/CPU2 without XRS_ low level external signal generation: that condition is new for me because I develop my code since long time. This issue is present either in FLASH STANDALONE mode but also when I ran code by RAM debug session (xds emulator lost connection). My power developed machine (ups) is connected by USB interface and monitored with sw console: I confirm, by state machine evolution on CPU1/CPU2, that my code undergoes in a internal reset condition without external XRS_ event (I checked a good 3V3 and 1V2 external power even if a POR event will must generate a XRS_ event).

I confirm that I don't use WD: it's disabled in the start_code_branch and also in the first instruction code after it was loaded from flash to ram or directly in ram. The problem is also present when I disconnect xds emulator (flash standalone mode so I don't think TRST_ may came into play).

So, Can ECC errors (RAM/FLASH) or bad memory access determinate this kind of issue? How can I understand what problem occur ?

I try to reconnect CPU1 after I notice xds emulator lost event but when I access to RESC register I see 0xC000000 value typically present after a reset event.

Finally, according your last advice, how can I avoid to use last 16 addresses of the flash bank and maybe ECC errors ? How can I modify my linker .cmd file to avoid this memory space ? Can this problem afflict my flash or ram code and consequently generate an internal reset condition ?

Thanks for your help.

Diego

  • 0
    TI__Guru* 87145 points

    Diego,

    Do you have an ISR for NMI?  ECC un-correctable errors will result in an NMI.  Since you are able to reproduce this, you might want to put a breakpoint in NMI ISR and see if control goes there.

    Also, check if there is an ITRAP.

    When you use the last 16 addresses of Flash, there is a possibility of ECC error or ITRAP occurrence.

    In linker cmd, you can reduce the length of the last sector as below:

    Existing:    FLASHN : origin = 0x0BE000, length = 0x002000 /* on-chip Flash */

    Proposed: FLASHN : origin = 0x0BE000, length = 0x001FF0 /* on-chip Flash */

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Intellectual 500 points

    Hi Vamsi.

    Thanks a lot for your advices: I'll follow them.

    Bye

  • 0 in reply to Diego Bellachioma
    Intellectual 500 points

    Hi Vamsi.

    Unfortunately, I'm struggling again with a random reset event issue. I'm searching a way to understand the boundary conditions that create this reset situation: I recover, on my sw console, RESC register status for a clear viewing on it's value after a reset condition occurs with code executed from flash. Obviously, I notice a correct value of it [0x4000_000] after a regular hw reset.When DSP board undergoes in a reset condition, while UPS is working or its power sections was started with a different time sequencing, the state of RESC remain the same and I sure that the DSP board is still powered.

    Have you got any advice to check something and therefore find the real culprit ?

    In the meantime, I check if there isn't any NMI ISR activated although I didn't remember any my explicit usage.

    Bye

    Diego

  • 0 in reply to Diego Bellachioma
    TI__Guru* 87145 points

    Diego,

    I may not be available until December first week.

    I will assign your post to our system control expert to help you further on this reset issue.

    Thanks and regards,

    Vamsi

     

  • 0 in reply to Diego Bellachioma
    TI__Guru** 115271 points

    Hi Diego,

    How are you confirming that device went through RESET cycle ? Did you put a breakpoint at your code entry point and CPU halt there hence you assume that device got reset? If yes then can you put breakpoint at reset vector (BOOTROM entry point) and see if CPU halts there. If it does then check the RESC register value and let us know the value.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 500 points

    Hi Vivek,

    Probably, the reset issue is caused by EMI noise when I start power section with common mode noise that can recirculate if 2 power device are in parallel relatively from AC and DC power rail of system.

    Unfortunately, I said there wasn't an external reset when it occured: how you can see from follow screenshoot I monitored XRS_ [CH4] pin during reset event and this fall down for a short period and then it rising up immediately; maybe, in the past, I didn't catch this event because my LH trigger level it was too lower. 

    Moreover, I don't can put any breakpoint to interrupt power synthesis and anyway I don't understand how can I obtain any information from breakpoint if I lost emulator control caused by reset.

    In conclusion, I filtered better VDDcore DSP power rail: before I had 22u after onboard DC/DC [TPS62420] followed by LC filter [bead + C = 10u near DSP]; now I replaced last 10u with another 22u. So far it seems a good solution: is one day that the reset event is disappeared!

    Thanks a lot for your support.

    Diego

         

  • 0 in reply to Vivek Singh
    Intellectual 500 points

    Hi Vivek,

    This morning the reset event is coming! :(

    I attach some oscilloscope waveform:

    From CH3 you can see reset activity during PFC starting task [CH2]: how it's showed I'm working, for now, at low voltage [in the past, I reached voltage up to 800Vdc]. Today the reset issue is coming when only PFC [loop is running on CPU1] is started [inrush event + soft-startup + steady state was interrupted!].

    If you look at screenshoot, where XRS_ pin is zoomed, you can see that it fell down for 520mV and than traced back in about 16ms related to reset capacitor [in the past I had pull-up 2k with 100nF -> now Cres= 4u7 ceramic 0805].

    I don't put break point if I'm not sure that I can stop Vienna-PWM generation, but I can insert Test Point LH edge action in some NMI to understand which error happen.

    I know that 4u7 Cres is too larger and maybe internal logic is not able to put down up to 0V the signal: I thought there was external spurious noise that generate external reset event, so I want to recover Cres = 100nF how TI showed with datasheet.

    Do you have some advice about what happen?

    Thanks.

  • 0 in reply to Diego Bellachioma
    TI__Guru** 115271 points

    Hi,

    I don't put break point if I'm not sure that I can stop Vienna-PWM generation, but I can insert Test Point LH edge action in some NMI to understand which error happen.

    Did you try having test point in code to see if any of the NMI getting set ? If device is getting reset then you should be able to set breakpoint at reset entry (in BOOTROM) and then check the NMI flag register. Right?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 500 points

    Hi Vivek.

    Finally, I found my culprit and it was an HW issue... First, I inserted TP toggling action in all ISR [NMI, FPU-MEM-FLASH,CLA, USER, etc.] with progressive activation of them to watch if them was triggered during the event. When I was confidant there weren't a SW issue that could cause the reset, I search some external condition (triggered by noise when pfc-vienna worked in hic-cup mode) that could generate the problem: so, I observed Vdd_core 1V2 when a noise could alter itself. Since, 1V2 was generated by TPS62420, I changed Cf in parallel to Rup to boost Phase Margin of DC/DC and thus permit that voltage loop could respond when output was altered (loop band extension).

    In conclusion, it is one week that reset issue is disappear.

    Thanks a lot for your support.

    Bye

    Diego

  • 0 in reply to Diego Bellachioma
    TI__Guru** 115271 points

    Hi Diego,

    Good debug. Board hardware debug are always time consuming. I am glad you were able to resolve it and thank you for sharing you experience.

    Regards,

    Vivek Singh