Code Composer Studio (5.5.0.00077) disconnected during debug on a TMS570LC4357 device

Hi Libo,

  What silicon revision do you have on ECU_1, ECU_2 and ECU_3? Are they are revA or revB of LC4357?

  From your description it is difficult to pinpoint why software B will result in lost of debug connection to the device. Can you elaborate how you write to the SYSECR in software B compared to software A? I tend to think the function that you call to generate the software system reset is the same between the two software, right?

  Can you monitor the nRST pin on the scope and see if you can tell the difference on the nRST between software A and software B when system reset happens. For example, is the active duraction of the nRST is the same between software A and software B or between ECU_1 and ECU_2?

  Can you also run software B on ECU_1 and software A on ECU_2?  Will you still see software A passing in ECU_2 and software B failing on ECU_1?

Hi Charles,

thanks for following up this thread.

All ECUs use the Rev A device.

Yes, the reset function is same in SW A and B.

SW A is for customer A, and SW B for customer B. The PCB design of ECU1 and ECU2 are different. ECU2 and ECU3 are both for customer B, and they have the same hardware design. Because of the different hardware design, I can't run SW A on ECU2/SW B on ECU1.

I had this problem before. But usually after a system reset in the debugger or reconnection, I can re-run tests without any problem. So I could live with that. Currently I try to verify that the system is reset upon certain error and some RAM variables contains the expected value after the reset. Because of the lost connection, I can't verify this.

Regarding the nRST pin measurement, it will take some time. I will come back to you if have further result.

Thanks and best regards,

Libo

 

Hi Libo,

  When you said software B was at one time working for you without losing debug connection, do you recall if it was an indentical software compare to what you have right now? Also were you using the same emulator and CCS version between then and now?

  Is it also possible for you to rerun software B on ECU_2 with silicon revB in it? The reason I'm asking is because there was an errata that we fixed in revB related to debug logic when the reset is active. However, I don't know if it will answer the problem you have becasue you said revA silicon was working for your software B in ECU_2 before.

  In revA silicon, if I hold an nRST input long enough I will see the device disconnected. In revB, this is fixed.

Libo,

I think that this issue is likely to be caused by some error in your software B. If you are using CCS to run the test, I would suggest you to change the instruction at address 0x0 from "b c_int_00" to "b #-8" for the debugging purpose. . With this change, CPU will loops around address 0x0 after reset. You can then use CCS or other debugger to control the test flow. With this change, no matter what error you have in the software, you will always be able to connect to CPU after a reset.

Thanks and regards,

Zhaohong

Hi Zhaohong, Hi Charles,

Due to software release timing, I couldn’t reply you in time. I’m sorry for that.

@Charles,

I have not checked the nRST pin with scope yet.

@Zhaohong,

Thanks for the suggestion. I tried that and it doesn’t help, the connection was still lost.

Actually the debugger is configured to stay at the address 0 after software reset. Before I thought that the debugger might start the SW again without halt at address 0, and there might be some bug in the software which triggered an endless reset loop. This loop made it impossible to create the connection.

 With the test suggested by Zhaohong, this case can be excluded since the SW can no more be started. After software reset, it stays at address 0.

 The software B above has been updated to B1. The main function is not changed between B and B1. It looks like this:

int main (void)

{

   EnableCacheEcc();

   EnableMemInterconnectEcc();

   InitRamConfig();

   InitPcrBusMasterFiltering();

   EcuM_Init();   /* start OS never returns */

   return 0;

}

 

I have run the following tests using the same ECU2 and software B1. In bootloader I have used the original code (b c_int00) instead of the loop (b #-8).

Test_B1_0:

I stop at the beginning of main(). Then I move the PC to UpdateDwwd(). As DWWD is not enabled yet at this time, the update will trigger a start time violation and a HARDWARE reset (DWWD reset). In this case, the debugger halts at address 0. The connection is available.

Test_B1_1:

I stop at the beginning of main(), or somewhere before EcuM_Init(). EcuM_Init() is a function from 3^rd party and it eventually calls our code (like InitIo, InitEsm, StartTask etc.) Then I move the PC to the code “Sys_Registers.Exception_Control = SYS_ECR_SOFTWARE_RESET;”. Step to the instruction “STR R1, [R0]” where R1 is 0x8000, and R0 is 0xFFFFFFE0. Click the step button, the connection is lost with this error message:

 I disconnect the debugger, keep the ECU powered-on,  tried to reconnect and get this message (Error 0xC0002240/-5008):

 

(correction to my first post: I wrote “after ECU power on, try to connect to the ECU”, it should have been “After disconnection, try to re-connect without re-power-on the ECU”).

This shows that hardware reset/watchdog reset is handled correctly by the debugger, but software reset is not.

 

Test_B1_2:

I DO NOT stop at the beginning of main(), instead, I just let the software enter EcuM_Init. And stop somewhere in our code, like InitIo. Then I move the PC to the code “Sys_Registers.Exception_Control = SYS_ECR_SOFTWARE_RESET;”. Step to the instruction “STR R1, [R0]” where R1 is 0x8000, and R0 is 0xFFFFFFE0. Click the step button, in this case the connection is still available and the PC is set to 0.

This shows that some code between main() and InitIo() has influence on how the debugger handles a software reset. As there are tons code from 3^rd party and codes from us between main() and InitIo(). I have no time to find out which codes among them are critical for the debugger’s reset handling.

I assume this could be a hardware error. As the software reset (writing the system ECR register) just set the PC to 0, there is no code after this write access. The expected behavior should be that the software reset can be triggered at anytime and the PC should then be set to 0. Even if the debugger has problem with this, I expect that the SW will start to run if I close the debugger. But I saw: after the debugger is closed, the current consumption is still very low, and If I restart the debugger, the connection can’t be created and I get the error 0xC0002240/-5008 as in the Test_B1_1.

For my current development, I just run the software till it is fully started (all tasks are started), and then test the reset behavior. It works now. Because of the delivery timing, I can’t spend too much time on debugging this issue. I will post new message, I have further information.

Thank you and best regards,

 Libo

Hi Libo,

  Can you let us know the MPU setting of each region?

Hi Charles,

The MPU is dynamically configured depending on the context. I don't have a list showing all the possible MPU configurations.

With "software reset" I actually meant to call the following function:

void WriteExceptionTrapDataAndReset(U16 exception_trap_data)
{
MK_DisableMpu();
Exception_Trap_Data.Exception_Data = exception_trap_data;
Exception_Trap_Data.Unexpected_Exception_Count++;
if(Exception_Trap_Data.Unexpected_Exception_Count >= MAX_NUM_EXCEPTION_RESETS)
{
Exception_Trap_Data.Stay_In_Boot = STAY_IN_BOOT_PATTERN;
}
FlushCache();
Sys_Registers.Exception_Control = SYS_ECR_SOFTWARE_RESET;
}

As you can see, we first disable MPU before we reset the system. Do you still need the MPU settings?

Thanks and regards,

Libo

Hi Libo,
What does FlushCache() do? It is only to disable cache or to disable cache and invalidate cache?

Hi Charles,

I am not very sure. I have checked the code, it seems that we only invalidate the entire first level data cache. The data cache is not disabled.

Thanks and best regards,

Libo

Hi Libo,
Can you try to disable both instruction and data cache and see if it makes a difference?

Hi Charles,

I set the break point after FlushCache():

FlushCache();
Sys_Registers.Exception_Control = SYS_ECR_SOFTWARE_RESET;

Then I manipulated the CP15 system control register with the following combination:
1. Only disable data cache
2. Disable both data and instruction cache
3. Only disable instruction cache

In all cases the connection is lost.

Then I set the break point before FlushCache(), manipulated the cache setting as above, the test result is the same: the connection is lost in all cases.

Thanks and regards,

Libo

Hi Libo,

  Since you said DWWD reset will not have disconnect issue, when you have a chance, can you measure the nRST duration between the reset caused by DWWD vs. Software reset? When you generate a DWWD reset, how does your external ASIC respond to such event vs. a software reset. Are they treated the same? Is the nRST being driven by external ASIC differently in any circumstances between a DWWD event vs. a software reset event? 

  As I mentioned in my earlier post, in revA silicon if I hold the nRST pin long enough I will see disconnect behavior. But in revB with the errata fix, I don't see this behavior. I also use XDS510 emulator.

Hi Charles,

OK, I will measure the nRST pin next week. I wonder why the SW can't resume running if I close/exit CCS debugger after the connection is lost. It seems that the MCU stays in a deadlock or in a state which it doesn't leave, and no code is executed at all.

Regards,

Libo

Hi Libo,

 Without doing the power cycle, will you be able to connect using a different emulator?

 If CPU is really stuck, I hope your DWWD is set up to cause an exception to take the CPU out of this situation. If you monitor the nRST you should be able to see the second reset event due to the DWWD.

  If you don't see the DWWD reset then it might lead me to think that the CPU's debug logic is somehow in an unstable or corrupt state due to the software reset event.

Hi Charles,

I haven't tested with other emulator yet.

I have measured the nRST pin and see no difference between the two cases. The pin goes from 3.2V to 0V and returns 3.2V after about 100us.

At the point where I can reproduce the error, the DWWD is not enabled yet. If I run to the point till DWWD is enabled, the error can not be reproduced (after reset, the connection is not lost).

Thanks and regards,

Libo

Hi Libo,

  Is it possible for you to send me small testcase that can still reproduce the behavior (lost connection) that you describe after a software reset?

Hello Charles,

as we discussed via email, the error disappears after I corrected both of the VCLK ratio and the VCLK2 ratio so that they are 75MHz (less than the max. allowed frequency 110MHz). Though I can't make your minimum test project run, I think this thread can be closed.

Thank you very much for the good support!

Best regards,

Libo