SAFETI-HALCOGEN-CSP: CAN1_UT_07:4 - Test canGetData API with data loss condition - fails

Hi Julia,

If the message with the same ID is received, the unread message in the mailbox will be overwritten. Since the RX interrupt is enabled, does the CAN ISR move the message from mailbox 4 to data register? 

No, the ISR in notification.c is blank when it is generated by HALCoGen and I do not see the xlsx file add ISR implementations either. What I do to use the CSP: I copy over the hcg and dil files from my application, change the configuration for the message boxes and interrupts and disable the CCM and CPU selftest options to allow for debugger attachment. Then I generate the code and run the tests. 

Everything works just fine but this one test case does not. I know by now that there are inter-dependencies in the test sequences such that I should not disable test cases up top because it can fail test cases down below. But for this test case failure, I had all test cases enabled.

Hi Julian,

If canMessageNotification() is empty, the CPU doesn't read the message from the message RAM, and the NewDat bit is not cleared. If a new message comes, the MsgLst will be set to indicate the previous message is lost.

Did you check if NewDat is set before re-transmit the message?

Yes, the test case already does that with the while statement shown above. it calls canIsRxMessageArrived to check newdat until it is set. I will now add a printing that lists all message boxes with that flag set after the re-transmission to find out if some other box stole it and report back.

Ok, so my printing experiment revealed a newdat indication for message box 4 and 7. So even though mb7 is left in default configuration, it will steal the retransmission. I made another test where I configured mb7 explicitly to be RX and enabled it, but since its configured id of 7 does not match, it will not take the retransmission. So far so good. Unfortunately the test does now only show newdat for mb4 (expected), but it still fails because canGetData returns 1 instead of the expected 3 (msglost).

********************************************************************************
*
* Executing Existing Test Case 19 in Sequence CAN1_UT
* File : C:\test\unit\halcogen\source\can.c
* Procedure : canGetData
*
********************************************************************************
newdat in mb 4                                           <------- The added printing, now ok
Input for node = (canBASE_t*) canREG1
Input for messageBox = (uint32) canMESSAGE_BOX4
Input for data = (uint8* const) rx_data

Call canGetData
No exception raised
Output for = 1 FAIL: expecting (uint32) 3   <--------- Still no msglost flag
********************************************************************************

So I am naturally wondering:

• Why does mb7 take the message when it is not configured? I have checked the sample project in the CSP and the mb7 config is exactly the same (HALCoGen default for every unused mb).
• Why do I still not get a msglost indication even though I have made sure that the message does not end up in any other mb?

The last point is kind of surprising to me because I thought mb7 stealing the message was the cause in the first place.

Another data point: I have tried to disable IRQ globally at the beginning of the testcase and reenabled it at the end. This had no effect. So it definetly is not an ISR clearing newdat such that msglost would not be set. I am getting the feeling that, for whatever reason, the CAN controller indeed does not set msglost when it has a new frame and it sees newdat already set. I do not assume this to be a general problem but I am out of ideas what could lead to this in my case.

Hi Julian,

I run some CAN TX/RX test this morning, got the same issue: MsgLst bit is not set. I don't see the newDat bit in message object in message RAM. 

So you do not see newDat at all? I do see newDat since the testcase waits for it and when I print, I check it using the driver API. Only msglost never happens.

So what could be the cause here? My thoughts:

• A general problem in CAN IP highly unlikely given design age
• A problem with the internal loopback would also be surprising as it would have been revealed by the creators of the CSP testcases
• Maybe some HALCoGen generated code has changed between initial CSP release and today and that change reveals the issue?

How do we proceed? Any ideas what we could try? I already disabled the other two CAN drivers to rule out some „cross-pollination“ in the generated code. Had no effect.

In my specific case I can disable the failing testcase and provide a lengthy justification that the msglost indication has no safety impact. But I would rather get to the bottom of this.

Julian Quindt said:

So you do not see newDat at all?

I don't see newDat in message object in message RAM. I read the message manually on CCS memory browser (direct RAM access). 

Julian Quindt said:

How do we proceed? Any ideas what we could try?

Actually many customers use HalCoGen CSP for peripheral unit test, and I didn't get report of this kind of issue before. I am wondering if we missed something in config.

I have tried a new and vanlla HALCoGen configuration for the 1224PGE by now. I only changed the required VIM and CAN config as per requirement in the xlsx. The problem persists. No msglost is set. Ideas what else I can try?

Hi Julian,

The test report in the folder of "..\SafeTI-HALCoGen-CSP\TMS570LS12x_11x_v04.07.01\HALCoGen\TMS570LS12x\CSP\Test\Reports\Regression Reports' shows that the test passed:

CAN1_UT.thr.htm

Yes, I am aware. But I cannot reproduce it, even with a vanilla HALCoGen config. Just to clarify, the mere interrupt arrival with an empty handler will not clear the newDat, only resetting it (e.g. using canGetData) will. Correct? Thats how I understand the test case. How can my vanilla config diverge from the one used by the CSP creators? I will do a diff on the sample dil files and see if that reveals anything. But I am not optimistic to find anything and really wonder whats going on here. Particularly since you were able to reproduce the issue on your end.

Hi Julian,

I did more test on L12x launchpad. I am not able to make the test pass.

Hi Julian,

I tested with a different HW setup: loop CAN1 to CAN2. CAN1 transmits message and CAN2 receive message. The MSGLST is not set either. I noticed that the data of 2nd transfer is not copied to the CAN2 message RAM. It is ignored. 

Thank you for checking and sorry for coming back late. I also tried a setup were I just had an eval board, an external CAN interface, a minimal configuration and program and the results were consistent with your findings. I could not convince the CAN IP to raise the MsgLost indication.

If you have any suggestions what else to try, I am here for it. Best regards

Without wanting to distract from the topic, are there any confirmation that the MsgLst register can be set to 1 on the TMS570, even outside of this test? I found this thread because I am encountering a similar issue on a TMS570LC4357ZWT (wanted to test for missed messages, could not make it happen).

Dear,

feel very welcome to add to this thread. 

While I cannot provide a different answer than „TI staff had the test passing when CSP was created“, these are factors I plan to look into next:

- HALCoGen version: Maybe a bug was introduced between the version used when creating the CSP and the latest one

- Role of ext. IDs: Just a shot in the dark, check if changing up ID scheme changes situation

- Role of HALCoGen default config: Maybe if I activate all other mailboxes and configuring them for TX, CAN IP will decide it is out of options for the second frame and finally raise MsgLost

- Role of enabled interrupt: Maybe disabling all interrupts might change CAN IP behavior when 2nd frame comes in

Will report back when I learn something.

Hi Julian,

Thank you to try different configurations. But I don't have other version of HalCoGen. 

Yes, that was it for me, too. Thank you so much. TRM is also clear on that point when showcasing how to set up a single messagebox for receival.

Hi,

yes, test is passing now. 

This was quite a head-scratcher. I feel either the CSP testcase instruction for the CAN unit tests should have included this in its messagebox setup instructions or, maybe even better, HALCoGen should have that bit set as a default value.

Thank you for your support.

My best regards