Porting MR-CANHUBK344 IEEE1722 to work with newer S32DS 3.5 and RTD 3.0.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Porting MR-CANHUBK344 IEEE1722 to work with newer S32DS 3.5 and RTD 3.0.0

Jump to solution
275 Views
nehalp
Contributor III

I'm trying to use the CANHUBK344 IEEE1722 demo app with S32DS 3.5 and RTD 3.0.0.

I followed the instructions and successfully got the project working with S32DS 3.4 and RTD 2.0.0 (per the instructions provided) and have successfully generated CAN bus traffic with it (as well as Ethernet).

I use the button on the board to generate a CAN message, as documented in the project guide.

I set breakpoints on the button_sw handler and in FlexCan_Ip_Send and can step through the code as it prepares the message and sends it, all the way through FlexCAN_SetMsgBuffIntCmd and can see the CAN message on my bus monitor as well as wireshark.

However, this does not work when I ported it to S32DS 3.5 and RTD 3.0.0

I've recreated the .mex file and project configuration in S32DS3.5, generated the pins and peripheral mappings, generated the code, and ported the application code to the point where it compiles and flashes onto the MR-CANHUBK344 board. However, right at the point where FlexCAN_SetMsgBuffIntCmd writes to the MB to send the CAN message, I see no data come out on my CAN bus monitor. 

Installed software:

nehalp_0-1702603841111.png

 

0 Kudos
1 Solution
232 Views
nehalp
Contributor III

I got this working. I had to double-check the clock configurations to make sure they were properly regenerated and CAN clocks were driven at 16MHz.

I also had to ensure enet.c had this modification on line 116-117. The macros changed from RTD 2.0.0 to 3.0.0:

//RMII mode
IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_EMAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_EMAC_CONF_SEL(2U);

View solution in original post

0 Kudos
1 Reply
233 Views
nehalp
Contributor III

I got this working. I had to double-check the clock configurations to make sure they were properly regenerated and CAN clocks were driven at 16MHz.

I also had to ensure enet.c had this modification on line 116-117. The macros changed from RTD 2.0.0 to 3.0.0:

//RMII mode
IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_EMAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_EMAC_CONF_SEL(2U);
0 Kudos