AM2432: HDSL Paramter Channel Communication In SYNC Mode

Hi Lars,

Can you share the ddr trace of memory using option 13 in uart menu for sync mode after running uart command 9 for long message? For that you need to build application in debug mode and select uart option 13. Also, can you share the waveforms for sync mode with your setup (sync, tx, rx, tx_en, tx_clk)? Going forward i need that info to debug the issue as i am not able to reproduce it.

Best Regards,

Rajul

Hey Rajul,

thanks for your answer.

The following steps I did do get a proper frame trace.

• Set trace_count to 300 in source code
• Start trace in function direct_read_rid81_length8 via set start_copy = 1 before the buffers are set to 0xFF
• At the end this function I print the trace to the UART terminal (to get a better view I only print frames which differ to the previous one in reference to the selected values)

The following trace is for SYNC mode and menu entry 09 which was successful:

The following trace is for SYNC mode and menu entry 09 which fails:

For reference the following trace is for FREE mode and menu entry 09 which alway succeed:

The signals HDSL_EN, HDSL_OUT, HDSL_IN from AM64x transceiver for SYNC mode:

Hope this information are helpful.

Thanks for your help and best regards

Lars

Lars
In the first image you shared, I see QM value dropping which is unexpected. Do you see communication break and protocol reset on the wire when the long message does not work successfully?

Regards

Dhaval

Hey Dhaval,

I checked the HDSL+ and HDSL- signals multiple times. We can not observere anything unexpected.

Please notice that picture one shows a successful parameter access in SYNC mode even though the QM drops.

In picture two there is also the QM drop but with an unsuccessful parameter access.

Overall I wondering that there is a QM drop anyway. The same hardware setting does not even produce a QM drop in FREE running mode.

Regards

Lars

Hi Lars,

Thanks for sharing these details, i will get back to you on this issue by tuesday with appropriate debug results.

Best Regards,

Rajul

Hi Lars,

With the memory trace you shared, i have found out that EVENT_L value is 0x26 for not working case and 0x06 for working case. Let's understand what that means according to HDSL spec (AM243x Motor Control SDK: TI HDSL Register List). EVENT_L bit 5 is set in not working case which according to spec means "When this warning is displayed, the Parameters Channel is still in the initialization status and no "short message" or "long message" can be triggered". Which means we need to check if we are trying to make long message transaction after clearing this warning. I have few questions in this,

1. How frequently you are seeing this issue? And how frequently you are triggering long message cmd?
2. Have you seen protocol resets in sync mode? Can you check NUM_RESETS (address=0x300027a9) value in memory browser?

Best Regards,

Rajul

Hey Rajul, 

refering to your first question:

All tests I did until now where made by manual selection of the menu entry. So the timespan between single long message transactions was in the scale of multiple seconds.

In addition I made a test by triggering every five seconds. I start 100 transactions. 23 were successful and the rest failed. The reset count (second question) is 78 after 100 transactions. One reset count is from the initialization before the menu is display the first time. 

To get more infomation I extracted all long message related bits from ONLINE_STATUS_D_HIGH & _LOW. This bits should be NON storing in contrast to the EVENT register which are storing. I now also clear both EVENT registers after each transaction. 

With the frame trace and the status bits I print out I observe the following three different cases:

1. Successful access, no NUM_RESET increment

2. Failed access, LINK is lost, PRST is set for one frame, NUM_RESETS++ (RES_COUNT++)

Thanks for your help and best regards

Lars

3. Failed access, no indication via status regs, only NUM_RESETS++ (RES_COUNT++)

Refering to your second question please see the picture above were I print the NUM_RESETS as RES_COUNT before and after each single transaction/long message.

Hi Lars,

I have tried to reproduce the issue you are facing with the same setup, same code changes related to ch1 and sdk version but i haven't seen any issue related to long message cmd(9) with 100 times trial. Can you please confirm which encoder specifically showing this issue? We have tested out solution with encoder EDM35, EKS36, EKM36. Also, we have not tested EES37 encoder with our solution. Is it possible for you to share the entire project with us so that we can align on same code?

Best Regards,

Rajul

Hey Rajul,

all evaluation results I posted here were obtained with an EES37.
I also run the tests with an EKM36 which lead to the same behaviour.

Sharing of the example project is not a problem. I attached the project on this post. Hope this works for you otherwise let me know where I can send it to /upload it for you.

Best Regards

Lars

SDK_11-00-00-06_hdsl_diagnostic_single_channel_am243x-evm_r5fss0-0_freertos_ti-arm-clang.zip

Hi Lars,

Can you please do few steps to make sure there is no sampling issue,
1. Put a breakpoint at "datalink_abort:" label in datalink.asm file
2. Put a breakpoint at "datalink_abort2:" label in datalink_init.asm file
3. wherever you hit long msg command, if break point hits, then please report the R6 value (just to make sure sampling is correct)

Can you please try this and share the r6 value after these steps?

Best Regards,

Rajul

Hey Rajul,

did several test runs: the R6 value is always 0x20005.

Best regards

Lars

Lars

What about the breakpoints? Do you see the FW hitting any of the breakpoints which Rajul mentioned above?

Also, is the cable length very small or close to zero in this case? Do we expect the cable delay to be less than 1 HDSL bit in your setup? Based on value 0x20005, it means that we are measuring 2 HDSL bit delay, which maybe incorrect for your setup.

Regards

Dhaval

Yes. FW hits the breakpoints when starting a long message transaction. The value of R6 is read when the core is halted on the breakpoint.

The cable length is approximately 5m.

According to the description of DELAY register and recorded values in the screenshots above the delay register indicates a cable length of <10. This seems to be correct for me.

Hi Lars,

Thanks for detailed f/w debug response. I have modified the firmware to fix the issue you are facing related to long message. Please refer to this f/w binary for PRU1 Channel 1 sync mode. Just replace it with existing binary in folder "source\position_sense\hdsl\firmware\multichannel_ch1_sync_mode".

hdsl_receiver_multichannel_sync_mode_pru1_bin.h
 

Let me know if you are still facing some issues.

Best Regards,
Rajul

Hey Rajul,

thanks for your answer and sorry for my delayed response.

With your firmware I got reliable long message answers and my test with 100 test messages is running without any protocol reset. So this issue is resolved. 

Can you explain what was the issue in the firmware? And will this be fixed in the next SDK release? In the debug traces on the serial console I observed a different behaviour of the RSSI value between the failing and the correct firmware. In the working firmware from you the RSSI value seems to be frozen at 1. The failing firmware was frozen to 2. Nevertheless this seems to be really bad values? In connection to this I might found a bug in the hdsl driver code.

This is the code from the hdsl_drv.c for the RSSI value which does not match the register description of the DELAY register.

Thanks and best regards

Lars