2006-06-21 11:24 AM
2006-03-21 08:52 PM
Hello,
we are using the str710 with HDLC : our transfert is like this : receive - answer - receive - answer etc... - when we are polling the HDLC receive line everything is working well like in your example we have : receive - answer - receive - answer etc... - when we want to use the HDLC IT: we have : RMC (ok) - TMC (ok) - RMC just after TMS (?- data n°1) - RMC (ok - data n°2) - TMC (ok) - RMC just after TMS (? - data n°3) - RMC (ok - data n°4) I notice that : data n°1 = data n°2 data n°3 = data n°4 but for data n°1 and data n°3 REN=1 : what does it mean? here is the code : init_hdlc : HDLC_ITConfig(HDLC_RMCM|HDLC_TMCM,ENABLE); EIC_IRQChannelPriorityConfig(HDLC_IRQChannel,4); EIC_IRQChannelConfig(HDLC_IRQChannel,ENABLE); void HDLC_IRQHandler(void) { if(HDLC_ReadInterruptStatus(HDLC_RMC)) { if (HDLC_ReadPCRStatus(HDLC_REN)==1) { HDLC_ClearInterruptStatus(HDLC_RBF | HDLC_RMC); HDLC_Recv_Control(ENABLE); return 1; } if (HDLC_ReadInterruptStatus(HDLC_RBF)) { HDLC_ClearInterruptStatus(HDLC_RBF); if (HDLC_ReceiveHalfBufferStatus()== HDLC_RECV_HIGH_HALF_BUFFER_FULL) recv_buf_addr = HDLC_RECEIVEBUFFER_BASE_HI; } bytecount = HDLC_RecvFrameByteCountRead (); for(addr = recv_buf_addr; addr{ pBufr[i] = (*(u8 *)addr); i++; } //here I put data in fifo HDLC_ClearInterruptStatus(HDLC_RBF | HDLC_RMC); } else if (HDLC_ReadInterruptStatus(HDLC_TMC)) { HDLC_ClearInterruptStatus(HDLC_TMC); HDLC_Recv_Control(ENABLE); } }2006-04-03 04:13 AM
I have not looked at your example in detail but there are some things about HDLC that are not included in the november reference manual.
Most importantly the REN and TEN bits are swapped on readback. So any operation that does a read modify write will do a read swap modify write! This could help explain your problems! The buffer addresses are incorrect in the HDLC example code/library supplied. The examples do not allow for the REN/TEN bits being swapped (unless updated recently) and also miss handles other aspects of the HDLC. Even with REN =0 you can still get new receive interrupts. Also the TX packet length can be corrupted in certain circumstances and I have not found a work around. The rx buffer can suffer over run and it not be reported in the bits that is meant to be. There are probably about another 10 'undocumented features' for this peripheral. I have not found all of them and I have been working on it for weeks. Your best bet may be to write a high speed logging routine that takes a snap shot of the HDLC registers and records any changes so you can download them later after the event. Slow your HDLC clock rates down and you can see how the peripheral actually works. It is quite different to the manual. Take any thing in the manual as a ''possible'' rather than ''likely''. Allow a few minutes to get HDLC talking and many weeks to get it working properly in all situations. Take great care running over unreliable links like RF as error recovery matters and that is very much unknown for this part (IMHO). Best of luck and let the group know about any HDLC 'undocumented features' you find.2006-06-19 02:46 AM
c_chris_us@yahoo.com
2006-06-21 11:24 AM
Quote:
Could you please send me your e-mail. Our marketing need to contact you to clarify for you some points about the HDLC. Ok - I was about to go bonkers until I saw the post about TEN and REN being swapped on read! Now I can safely cancel my psych visit. Can somebody from ST do me a favor and mail me the correct docs and library code to kgrobler at hotmail.com? Thanks