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.

TMS320F28379D: Function causes watchdog reset, when being placed in RAM

Part Number: TMS320F28379D

Dear TI experts,

I have the following problem with a function:

- If I place the function into the flash, it runs nicely without any problems

- If I place the function into the RAM and execute the code with the debugger, it runs as well without any problems

- If I place the function into the RAM and it is executed "standalone" without any debugger intervention, it crashes and causes a watchdog reset

I cannot identify any suspicious code that could cause this behaviour, I think it must have something to do, with the size of the function, or with the placement of the function in the RAM. If I reduce the code size of the function (even code that is not executed during the function call!), it will also run nicely from the RAM. What really surprises me is the fact, that I don't see the crash, when the code is executed with the debugger. I am aware, that the debugger disables the watchdog, but my application has an additional "user watchdog" that monitors the program flow of CPU2 (this is the CPU where the suspicious function is exectued). CPU1 checks the program flow of CPU2

In the map-file I see, that the function is placed in global shared RAM, in fact at address 0x1_8000 which is the start address of GS12_RAM. The size of the function is 0x305 (16 Bit words I suppose)

If the problem is related with the code size or the placement of the function, I would expect to get a warning, or an error from the linker or from the compiler.

Can I retrieve any additional information after the watchdog reset, apart from the information that the reset cause was a watchdog reset? The RESC-register provides the information, that the reset cause was a watchdog reset.

  • Hi Sieghard Kotz,

    When you say you run from RAM standalone, do you copy the code from flash to RAM?
    If you load the code to RAM and allow it to run standalone, the RAM content will get erased after a power-on reset. I hope you have loaded the code into Flash and then did a memcopy to the desired RAM location.

    Regards,
    Veena
  • Hi Veena,

    thanks for your help.

    The code is copied from flash to RAM in my memory initialization function. The code is copied correctly, this is what I see, when I step through the code with the debugger. If I had the possibility to connect to my target without reset, I could see the position of the program counter. Do you know how I can connect to the target without resetting it? I just want to connect and halt the target without a reset. Since the code is running flawlessly when I program and execute it with the debugger, I don't have a chance to identify the cause for the watchdog reset.

    Best regards,

    Sieghard

  • Do you know how I can connect to the target without resetting it?

    Remove the gel file from target configuration file (.ccxml) and connect to the target. this will not reset your target.

  • Hi Baskaran,

    this resolved my issue!

    Now I see, that CPU2 is running into an illegal code trap (ITRAP0). The function that causes the trap is not copied entirely into the RAM, because CPU1 is concurrently initializing the RAM. The global shared RAM where the functions of CPU2 are supposed to be running, is not yet fully assigned to CPU2. Synchronizing both CPUs with an IPC-event solves the issue. This also explains why I didn't see this behaviour when executing the code with the debugger. The timing is different since I start the execution of CPU1 and CPU2 manually and successively.

    Best regards,

    Sieghard