Home/Support/Support Forum/printf functions in API mode for S3b 900HP giving trash

printf functions in API mode for S3b 900HP giving trash

0 votes
I am utilizing the printf() function to debug my application software deployed to a Freescale programmable S3B 900HP, and lately it has been spitting out garbage when observing the terminal. (have tried RealTerm and XCTU)

My PC is talking to both systems via separate COM ports.

S3B Monitor = XBIB USB, COM16
S3B Transmitter = Grove USB, programmed w XBIB, COM21

This is what is shown on the Transmitter serial port after xbee_disc_discover_nodes() is executed from the code:

¯º9Ž6ËÇAå´±º9¤U–kWÑA´·â³º½,÷Aå´±º9¤U–kUÑA´·ë壯²ºÎÔkÕ埶KWíA²±º=®K
kA鵸·9-¤ö¯ºŽ6ËÇAå´±º9¤U–kWÑA´·¢¨—+‹Ý倻º­jçÝɤºÕÿ³º½,×+Aå´±º
A´·Ù

And the very standard sys_app_banner():

†#AÉÕª´µuY•‹§ÉÕª¶µ5UZ­•‹§ÉÕª¶µ5]­•‹§éÕª¶µµUŠáÙ©³8­­Ë§‚VÍÝ“¯·KW½å´µ·¶J€
…%)ÕA­·²=¯V‚Nm…€“²·¡S[¸.U¨Ò…uŠÑɲ±î’‚>&¦ªÂÁ5a`­˜˜+$¦ ¶ÁA …uòÕå³
µË¤‚Âá**AÝ@†«;9îVëçAu ˜¼……@åUÑí¯º

PJÒ‚ÕQea†«§éÕª¶µ5UZ—‹§ÉÕª¶µµU[•«§ÉÕª¶µµU[•«§ÉÕª6)5ÿ


It never even registers/is observed on the Monitor side. Usually it comes out just fine. The trash thing is a recent development. I have tried formatting in ASCII, Ansi, Hex(space), Hex+ASCII, etc. So really this is happening at the Transmitter and not so much the Monitor.
asked Aug 10 in DigiMesh Proprietary Mesh Networking by D2K New to the Community (12 points)

Please log in or register to answer this question.

2 Answers

0 votes
 
Best answer
An update to this issue.

Since baud rate is clock derived, I am assuming that me clocking the processor down to 16 MHz (to reduce power) had been what the issue was, because all of my serial terminal output looks great now. My baud rate was originally set to 115,200.
answered Aug 11 by D2K New to the Community (12 points)
0 votes
I am beginning to wonder if this is a result of how the Ember and Freescale serial ports are configured locally, considering the interactions between the two when using the programmable variant in API mode. I can't imagine it being anything else considering the error occurs directly at calls to the UART device level code.
answered Aug 11 by D2K New to the Community (12 points)
edited Aug 11 by D2K
...