Electronic – Microcontroller writes additional data on high-frequent writes

atmegacommunicationmicrocontrollerrs232

I'm using C-Control Pro 128 which contains a atmega processor. I've connected the rs232 interface with my PC and read the incoming data, having the following program executed on the controller:

void main(void) {
  Serial_Init(0, SR_8BIT | SR_1STOP | SR_EVEN_PAR, SR_BD9600);
  Serial_Write(0, 1);
  Serial_Write(0, 2);
}

I'd expected the controller to output the bytes 1 and 2. Instead, I receive the following:

If I write e.g. eight bytes instead of two, 119 is appended eight times to the actual data. If I write only one byte, only the one byte is transmitted, so all works correct.

The number 119 is independend from the value of the bytes and from the baud rate.

If I add a sleep instruction between the write commands (about 50ms), the problem does not occur.

Has anyone had a similar problem or any idea where the problem could be located?

Best Answer

The way to diagnose these sorts of problems is to cut them in half. Whose fault is this? The C-Control or the PC? If we can look at the actual data sent on the wire, we can tell whereabouts the fault lies.

Start by sending a simple, easily identifiable character, over and over again. I like to use the one used as an example on the Wikipedia's RS232 page because you can easily see what the waveform is supposed to look like.

K RS232

Now you'll need an oscilloscope. If you can't afford one, I highly recommend the Saleae Logic analyser. It's not that expensive, and it will save you literally days off your life. Look at the waveform on the bus, and check that it matches the waveform you expct. Check for any rogue characters transmitted afterwards.

Assuming everything looks OK, then the problem is somewhere in the PC. If the rogue 119 characters appear, then you know the problem is in the C-Control

Related Solutions

Electronic – Microcontroller Sleep Race Condition

There is usually some kind of hardware support for this case. E.g., the AVRs' sei instruction to enable interrupts defers enabling until the following instruction is complete. With it one can do:

forever,
   interrupts off;
   if has_flag,
      interrupts on;
      process interrupt;
   else,
      interrupts-on-and-sleep;    # won't be interrupted
   end
end

The interrupt that would have been missed in the example would in this case be held off until the processor completes its sleep sequence.

Electronic – STM32 USART with DMA — which interrupts to use

You can configure DMA to work in cyclic mode, and with reasonable big buffer you can pull characters as often as you want with simple poll function. Just store index of last character retrieved and use DMA register to check how many characters it has to receive until roll over (AFAIR register has NDTR in its name), and process characters received since last call, then update index of last character retrieved.

Described DMA usage makes your poll independent from context you call it from as long as you prevent preemption. Then you can use RX interrupt to trigger poll call(s), or you can do it in other context (for example with some periodic events).

This is generally efficient if frames are long enough, baudrate is big and interrupt latency is bigger than reception time of single char.

But if data is received slow enough you can get away with processing it char by char current way, and using DMA may be overkill.

As @Chris Stratton pointed you can also just set DMA for single transmission, and wait long enough, change protocol or use other signal as "end of transmission" - and then process frame in DMA buffer.

Best Answer

Related Solutions

Electronic – Microcontroller Sleep Race Condition

Electronic – STM32 USART with DMA — which interrupts to use

Related Topic