LP-MSPM0G3519: MCAN_TXBTO does not update after resuming the code from breakpoint.

Hi Kiran,

Looks like that if the Tx buffer transmission occurs with the breakpoint, the TXBTO register is not udpated. I will take a test to check if this is expected.

B.R.

Sal

Hi Kiran,

I have tested the SDK version with TXBUF and breakpoint, looks like it works normal within my test. I will check with MCAL team to see any suggestion here.

One thing I want to check with you:

Kiran Ghorpade said:

When the code runs fine without a breakpoint, we observe that the register MCAN_TXBTO updates correctly, indicating that the Tx Buffer Transmission occurred.

Do you use the different TXBUF to send the message, or use the same TXBUF to send the message and then find it doesn't changed accordingly?

Additionally, what is TXBCF bit status:

B.R.

Sal

Hello Sal,

Thanks for the response!

We are working on "MCAL_MSPM0_00.02.05.00_Internal". Does the SDK version mean the same?

We are transmitting one message, and for that, we have done the following configuration:

We have tried with different "CanHwObjectCount" values from 0 to 1; however, the result is the same.

We don't see any update in the TXBCF register. Please find the screenshots below.

Tx register status in Run time (Before breakpoint, when transmission works properly)

Tx register status after breakpoint, re-run scenario (transmission stops)

Please let me know if you need any additional details.

Regards,

Kiran

In above message, I mean to say "We have tried with different "CanHwObjectCount" values from 1 to 8; however, the result is the same."

Hi Kiran,

Thanks for your information, forwarded to our MCAL team to verify. Will feedback to you when there is an progress.

B.R.

Sal

Hello Sal,

Is there any update from the MCAL team regarding the issue?

We are also checking the issue at our end and have some observations to share with you, along with a query.

Please find below the screenshots of the registers for your reference.

• Status of the registers during normal runtime: when transmission works.

• Status of the registers when we stop the execution.

• Status of the registers during re-run of the code after halting the execution.

We tried to manually change the CANFD0_MCAN_CCCR.INIT bit to 0

and changed the free object count “Can_DriverObj.canTxMessageObj[0].freeHwObjectCount” value to a configurable value. Transmission started again.

Could you please explain why the CANFD0_MCAN_CCCR.CSR and CANFD0_MCAN_CCCR.INIT bit change when we halt the execution using a breakpoint or simple break command?

Regards,

Kiran

Hi Kiran,

Thanks for reminding, currently no comments from team.

Let me check and discuss with the team.

B.R.

Sal

Hello Sal,

Is there any update from the MCAL team regarding the issue?

B.R.

Kiran

Hi Kiran,

Sorry for the late response. I am OOO these days.

When check the CANFD0_MCAN_CCCR.CSR, could you check below register value:

Please check MCANSS_CTRL.DBGSUSP_FREE bit, maybe some code set it as "0".

B.R.

Sal

Hi Kiran,

Thanks for feedback.

I will set up an internal tracking thread and take a fix.

Any further comments I will update here to you.

B.R.

Sal

Hi Kiran,

By the way, is there any configuration could select and set the 

initParams->emulationEnable = (uint32_t) MCAN_EMU_DISABLE ?

For my understanding, when enable the debug emulation mode, then it means that user want to use suspend mode, so it is required to set

"DBGSUSP_FREE" as zero.

Then, looks like the MCAL has correct macro definition here.

B.R.

Sal 

Hello Sal,

Thanks for the response.

In the current configuration, there is no parameter to enable or disable the debug suspend mode.

If the MCAL has the correct macro definition for "DBGSUSP_FREE",
then I think some additional implementation is required in the static code to re-enable the MCAN clock and set the MCAN to Normal mode after resuming execution from a halt.
As we have seen that CANFD0_MCAN_CCCR.INIT changes to 1 when execution is halted using a breakpoint or a simple break command.

B.R.
Kiran

Hello Sal,

Any update on above topic.

Regards,

Kiran

Hi Kiran,

Sorry I am OOO in next few days.

I'll check early next week.

B.R.

Sal

Hi Kiran,

I got internal team confirmation that this will be fixed in next release.

B.R.

Sal

Hi Sal,

Thanks for the update. Noted that the fix is planned for the next release. 

Regards,

Kiran