AM2432: CCS Debugging causes timing problems

Hello Alexander,

Actually, when you use the DebugP_log, this API is used to write data on UART Registers .

So, before writing data on the UART registers all the interrupts will be disabled . Once writing operation is done. It enables all the interrupts. Due to this, you may get interrupts delayed. But, FIQ mostly does not have an effect ..Since FIQ is the highest priority rather than IRQ and in MCU+SDK in all critical sections we disable only the IRQ's and not FIQ's. So, FIQ's mostly don't get an effect.

Please share details about which peripherals are configured to either IRQ or FIQ ?

As per the above comment, there is no debug_log enabled in core 2.

So, I assume that these issues come in core 1 ? 

Please confirm.

Are you using the same UART in both cores ?

Are you using IPC in your application ?

Are you using debug log in core 2 as well ?

Alexander Baehr said:

The problem is gone if the software is running from flash

Which build is this release or debug build ?

Regards,

Anil.

Alexander Baehr said:

Why would the debugging session halt the system in case of DebugP_log?

Have you unintentionally enabled "Halt the target before any debugger access"? Just something to eliminate.

No, this item is disabled. .

(If I knew the file where the debug settings arelocated, I would attach it ...)

Thanks & BR

Alexander

Digging further into it, the problem is NOT depending on DebugP_log(). It is sometimes there and sometimes not, but only when using debugger. So we have to look at the whole debug environment.

BR

Alexander

Hello Anil,

Debug messages from Core 2 go via Shared Memory Log Writer, Shared Memory Log Reader, to UART. This is actually working.

I agree that the problem ist most likely on core 1. So, further information refers to core 1.

We have three EPWM interrupts realized as FIQ. One software interrupt HwiP_post() triggered by as an IRQ. And quite some modules from sysconfig:Clock, MPU, EPWM, GPIO, MCAN, QSPI, Debug UART, ETHPHY, FLASH

I verified that I cannot cause the effect when I HWIP_disable() for a longer time.

I don't understand IPC - if you mean the spinclocks (<drivers/spinlock.h>), I have already removed them in my debugging code.

I am using the Debug build of my program for both debugging and flashing. The SDK libraries are acually used in different versions:

${INHERITED_LIBRARIES}
${SYSCONFIG_TOOL_LIBRARIES}
${COM_TI_MOTOR_CONTROL_SDK_AM243X_LIBRARIES}
freertos.am243x.r5f.ti-arm-clang.release.lib
drivers.am243x.r5f.ti-arm-clang.release.lib
enet-cpsw.am243x.r5f.ti-arm-clang.Debug.lib
lwip-freertos.am243x.r5f.ti-arm-clang.Debug.lib
lwip-contrib-freertos.am243x.r5f.ti-arm-clang.Debug.lib
lwipif-cpsw-freertos.am243x.r5f.ti-arm-clang.Debug.lib
board.am243x.r5f.ti-arm-clang.Debug.lib
libc.a
libsysbm.a

BR

Alexander

Hello Alexander ,

Based on the above comments , you have confirmed that this issue is not coming with the Debug_logp and with the debugger connection.

Kier said:

Have you unintentionally enabled "Halt the target before any debugger access"? Just something to eliminate.

Please check any other debug configurations except the above one . I am not familiar to the above debuggers .

If you still face the issue needs help from us then I can reassign it to the right expert.

Regards,

Anil.

Hi Anil,

here are my debugger settings from the CCS project for the 1st core. I cannot find anything suspicious. Any idea what I should change?

BR

Alexander

Debugger settings.zip

Hello Alexander,

Disable the ticks for the below options and check the interrupt timings when the debugger is connected.

The XDS 560V2 debugger we don't use in the MCU+SDK level.

Meanwhile, I can check internally with other Team members about these debugger settings.

Regards,

Anil.

Hello Anil,

I removed both items in the 1st and 2nd core, but the problem remains. Sorry for the confusion about  "Halt the target before any debugger access".

What can I try next?

BR
Alexander

Hello Alexander ,

Internally, I need to check for the debugger settings and will update the status.

Regards,

Anil.

Hello Alexander ,

I am using the XDS 110 debugger and capturing the images of XDS debugger settings for your reference .

I have looked at them. Your settings and mine settings seem the same and some are different .

I don't think the change will not create an issue . But, you can try to opt my settings and see the the results.

Meanwhile, can you please confirm how did you confirm that IRQ and FIQ are not triggering at particular time .

Is it based on the GPIO or any Timer based ?

If it is Timer based then which timer you are using for profiling ?

I hope during debugging you don't stopping  the debugger and profiling IRQ's ..If you stops the debugger , which will also affect the IQR/FIQ profiling .

Please confirm .

Regards,

Anil.

Hello Anil,

in the attached image, yellow is the PWM output, D0, D2 are GPIOs indicating two FIQ interrupts on Core 1, and D3, D4 are GPIOs inidicating two FIQ interrupts on Core 2. Below is a zoom of the above. The PWM is sunning constantly, but the interrupts are block for some 300 ms.

I made a test with a Spectrum Digital XDS200 debugger available and the result was the same.

No, I do not stop a core manually.

What about profiling? Where can I switch it on and off?

BR
Alexander

Hello Anil,

I was able to track down the issue to a call to std::time(NULL) from background task. If I cut this out, I cannot reproduce the error any more.

How does this interfere with the debugger?

BR
Alexander

Hello Alexander,

Can you please share the full API std::time (NULL) and file details ?

I can check and come back.

Regards,

Anil.

Hello Anil,

I don't understand your question. The critical instruction is

if (<trigger event>)
{
    debugVariable = std::time(NULL);
}

This instruction returns a time value in debugVariable, but causes the timing issue. std::time() is a standard function from C++ compiler API. If there is something I can configure about this function, please give me a hint.

BR

Alexander 

Hello Anil,

Swargam Anil said:

To get the current time value we need to enable the  timer and get time stamps from the same timer whenever you wants and the same method we follow in MCU+SDK.

Thank you for that hint. I am going to discuss that with my colleague,

Digging into the API source code, ist seems that std::time() is actually calling the host for the realtime value ... 

ccs1260\ccs\tools\compiler\ti-cgt-armllvm_3.2.1.LTS\lib\src\time.c
ccs1260\ccs\tools\compiler\ti-cgt-armllvm_3.2.1.LTS\lib\src\hosttime.c

BR
Alexander