STM32VL-Discovery: Different behavior sending over UART for same model

[an]

Posted on December 06, 2013 at 09:35

Hi together,

I have a couple of STM32VL-Discovery boards, with each holding the same firmware. The firmware essentially does nothing more then sending 8kb of data over UART.Furthermore, I have a custom controller board, to which up to 16 STM32s can be connected. The controller board iterates over each STM, receiving its data and transferring it to the desktop. Thus, I can read out the boards in an automatic fashion.In

particular

,  the board under test gets powered, the controller then first waits 100ms, then it starts monitoring the board's serial output. As long as datais being received the board remains powered. When no data has been seenfor 30 time periods (which should be roughly equal to 22 bytes over theserial port, the controller assumes that transmissions have finishedand powers up the next board. However, the interesting observation is: that out of 10 boards, there are 3 boards for which the whole 8 KB are received. The others would only transmit a fraction (around 440 byte) before the controller switches to the next one. Thus, there must be some kind of delay for some boards sending the data even though all boards have the same firmware image and all are the same model. The code is ASM and thus should be quiet fast to be executed.My question now is: how can it be that for some boards this works an for some it does not (always the same boards, not changing)? Is there some kind of additional delay / buffer/ caching mechanism which can be disabled?Regards

[Andrew Neil]

Posted on December 06, 2013 at 10:29

''...a custom controller board...''

Could it be a problem in the controller board?Are the other boards running from crystal?

[frankmeyer9]

Posted on December 06, 2013 at 10:29

Have you checked real events on the Rx/Tx line ?

It is presumably not difficult to catch such an ''error event'' with the scope, using a GPIO of your master boards as trigger. How about the power supplies of your board ? Could a shift in potential/grounding create phantom receptions or disturb reception ? Does you protocol involve some kind of error checking ? RS232 is rather error-prone, I would suggest both error checking and some handshake (e.g. RTS/CTS).

[an]

Posted on January 13, 2014 at 14:13

Hi together,

I tried to check whether it is a problem with the controllerboard by1.) rearranging the order of the connected STMs. However, the order has no influece on the behavior. Its always the same boards that have an odd behavior.2.) changing the number of connected STMs. Also the number has no influence on the behavior.3.) Furthermore, the contorllerboard worked for other STMs (ST32F0xx).The boards are running from crystal.I havent checked real events on rx/tx. I am working here under not optimal conditions. Right now I have no access to a scope... I only get the chips delivered, have to implement the firmware and get the results.The UART communication is without hw flow or error correction at all. However, using RealTerm as the terminal software, I get no errors while letting the boards run on their own (directoly connected via UART to USB converter). Using the controller board RealTerm indicates an UART error during transmission (but only for the boards with odd behavior).I also received another chip for the controllerboard which accepts  larger delay (250 ms) before proceeding to the next STM32. Here the STMs with odd behavior keep on sending SRAM data in an endless fashion. This is strange since the firmware is the same for every STM.

[chen]

Posted on January 13, 2014 at 15:41

Hi

''I have a couple of STM32VL-Discovery boards, with each holding the same firmware.'' ''However, the interesting observation is: that out of 10 boards, there are 3 boards'' So which is it - do you have 2 discovery boards or 10? I am confused about what boards you are actually using to send! ''The firmware essentially does nothing more then sending 8kb of data over UART.'' What is the data ? Is it a fixed block of data, calculated data or is it aquired/digitised? ''When no data has been seenfor 30 time periods (which should be roughly equal to 22 bytes over theserial port, the controller assumes that transmissions have finishedand powers up the next board. '' Depending on the answer to my previous question - this could be a BIG assumption! ''However, the order has no influece on the behavior. Its always the same boards that have an odd behavior.'' So the problem follows the 3 boards. Good - you have narrowed the problem to the boards