0
\$\begingroup\$

I am using an RS 485 serial connection through which I need to send S19 files for my boot loader project. Since it is a half duplex mode of connection, I need to toggle a dedicated pin before sending and receiving. I am using this terminal application. I got the desired output when I sent a string.enter image description here

But I couldn't get any output when I try to load a file (s19 file to be specific). Is it because of the Half-Duplex connection I use ? Will an RS 485 to RS 232 converter change the mode from Half duplex to Full duplex ?

UPDATE

I am working on Freescale's MKE02Z64VLD2 microcontroller. I just now found out that there is no RTS CTS pin in my controller. (Check Comment Link 1)

This is the Serial connection which I use, enter image description here

And the Terminal application is not a boot loader GUI, I found it in this site. (Check comment Link 2) Thanks for helping. I am posting the Links in the comments section because I dont have enough reputation to post more than 2 links

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Do you have CTS connected? If not then you should change the handshaking to 'none' or 'xon/xoff'. Otherwise the PC won't send because it doesn't think the other end is ready to receive data. \$\endgroup\$ May 9, 2016 at 4:41
  • \$\begingroup\$ Sounds like a protocol as well as a hardware miss-match issue. To make this work you will need an intimate understanding of your s19 data in terms of signal protocols, than maybe you can write a piece of code for a proper interface. What exactly happens when you send a string? Look into the fine details. You may have to do some bit-bashing to make this work. \$\endgroup\$
    – user105652
    May 9, 2016 at 5:05
  • \$\begingroup\$ @BruceAbbott . Thanks I'll try changing the Handshaking to any of the 2 and look for the output. \$\endgroup\$
    – R.Gechu
    May 9, 2016 at 5:47
  • \$\begingroup\$ @Sparky256 This is my code which sends the string for(;;) { GPIO_PDD_TogglePortDataOutputMask(GPIOA_BASE_PTR, GPIO_PDD_PIN_21); CLS1_SendStr("Hello World!\r\n", CLS1_GetStdio()->stdOut); WAIT1_Waitms(1000); CLS1_SendStr("Welcome Ganesh!\r\n", CLS1_GetStdio()->stdOut); This gives me the desired output. \$\endgroup\$
    – R.Gechu
    May 9, 2016 at 5:52
  • \$\begingroup\$ "I got the desired output when I sent a string... But I couldn't get any output when I try to load a file (s19 file to be specific)." S19 files are strings. So your problem is not that your bootloader can't receive the s19 file, but how it processes the data. If you don't have flow control (xon/xoff, or RTS/CTS if available) then the bootloader may not be able to keep up with the incoming data rate while writing to Flash at the same time. \$\endgroup\$ May 11, 2016 at 16:51

2 Answers 2

4
\$\begingroup\$

No. A converter merely changes the electrical signalling and gives you an explicit (typically modem control line reuse) or automatic (time based) control of the transmit enable.

Adaptation to a half-duplex scheme must be made by the software at each end.

As for why exactly your setup failed, that is impossible to answer with the limited information given, however it software not written with this mode of communication in mind could be a key part of the problem.

\$\endgroup\$
0
\$\begingroup\$

At this point you should expand your question with morerdetails: what MCU board do you use, what rs485 transceiver you use (wiring), on the PC side what RS232/485 converter? If your bootloader (PC and MCU) work in half duplex, PC sends data and waits for ACK from MCU, the MCU awaits data and after receive sends ACK, no communication in both directions ever exists. Only then you can set the terminal to use RTS on TX - this implies that the rs232/485 converter uses RTS from rs232 to enable/disable transmission on rs485 (it's a specific converter). The same has to be done on MCU, rather using toggle command use set/reset. The success is at any time under question, if you don't have full access to patch the bootloader adding extra timeouts, hw handsake..etc. Is the terminal window on your picture a bootloader GUI?

\$\endgroup\$
7
  • \$\begingroup\$ I have expanded the question sir. I have not made any changes in the boot loader code with respect to Half Duplex. I wrote the code thinking that it is a full duplex connection. But later when I tested the code only I found that I missed the main issue here (Which Is Half duplex). SO I thought of testing simple codes to send and receive strings and then try to send a .s19 file. If I am successful with that I can incorporate the same logic in my Boot loader code. LINK 1: community.freescale.com/message/643594#comment-643594 LINK 2: sites.google.com/site/terminalbpp \$\endgroup\$
    – R.Gechu
    May 11, 2016 at 12:06
  • \$\begingroup\$ Not familiar whith those devices, but possibly easy solution is to set RTS, then transfer the data to be send in a fifo that is binded with DMA->UART_TX, and search if the DMA is capable to issue a interrupt when fifo beomes empty (meaning has sent all characters), at that point you reset the RTS \$\endgroup\$ May 11, 2016 at 13:41
  • \$\begingroup\$ That is where the next problem lies. RTS, DMA mode are available in my IDE (Kinetis Design Studio) but the controller (MKE02Z64VLD2) for which I am designing boot loader does not support CTS, RTS. \$\endgroup\$
    – R.Gechu
    May 12, 2016 at 6:20
  • \$\begingroup\$ Yes, I got that. Let's call it TX_EN instead(a GPIO), now change in my previous comment, RTS with TX_EN. Set up transmit trough DMA, and set interrupt at DMA Tx fifo empty. \$\endgroup\$ May 12, 2016 at 9:15
  • \$\begingroup\$ You don't need DMA to keep up with a moderate baud rate like the 38400 shown (or even 115200), and trying to use it is only likely to make managing the link direction more complicated, especially for someone with the asker's apparent inexperience. \$\endgroup\$ May 12, 2016 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.