This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

P89LPC932 and serial communication, strange phenomenon

Following set:
Two identical PCBs (my hardware design using the LPC932), one with the "real" MCU, other with connector adaptor to EPM900 board.
My software runs smooth on the emulator. I always send 24 bytes via COM5 (virtual COM port of FTDI232 USB-to-RS232 chip). The MCU processes the 24 bytes, executes a command, some routines and sends 24 bytes back to PC.
The 24 bytes are a certain telegram with a two byte header and a checksum at the end.
So far, so good. As I said, it runs smooth on the emu.
But when I flash the compiled hex file into the LPC932 on the other board and connect this board with USB (COM5), I can send the 24 bytes to COM5, but I receive an error code generated by my firmware telling me the header is wrong.
I found out that the last, the 24th byte, is somehow coming to the first position of the serial input buffer. Example:
PC sends: AA 55 00 FF .... FF 60
hardware should have: AA 55 00 FF ... FF 60
in the 24 byte input buffer, but it has: 60 AA 55 00 FF ... FF
No idea. Code is fine, I worked it out a thousand time. The whole buffer seems to be shifted. I repeat, this runs correct on the emu, which holds the same MCU.

The worst fact is, that sometimes the code in the "real" MCU runs correctly after being connected to supply voltage (USB), sometimes it doesn't. So the code must be ok.

Any clue?

Thanks for any help.

Parents
  • So no variable could "come up 0 or FF". I didn't speak about 0s or FFs, I spoke about the last byte of the transmission somehow wanders at the first byte of the input buffer.
    If you write buffer[offset & ...] as is usually done the difference between 0 and ff would EXACTLY show the phenomen you describe.

    I'm not completely sure if I got you correct.
    As you can see in the code example above, it writes to buffer using a pointer. With the first byte coming in from the UART, the pointer is set to the beginning of the I/O buffer structure, the byte is written into it and the byte counter is incremented. Next round the pointer points to the second byte in the I/O buffer and so on. After 24 bytes the byte counter and thus the pointer are reset with the next byte coming in.

    Und wenn der Code dort eine Struktur aufbaut, die anschließend beim Boot-up mit Nullen überschrieben wird, wo soll da was nicht richtig gesetzt oder initialisiert sein? only if startup.a51 match your actual situation.
    As I told before, I have a function which clears the I/O buffer with zeros at startup and after every 24 bytes received.

Reply
  • So no variable could "come up 0 or FF". I didn't speak about 0s or FFs, I spoke about the last byte of the transmission somehow wanders at the first byte of the input buffer.
    If you write buffer[offset & ...] as is usually done the difference between 0 and ff would EXACTLY show the phenomen you describe.

    I'm not completely sure if I got you correct.
    As you can see in the code example above, it writes to buffer using a pointer. With the first byte coming in from the UART, the pointer is set to the beginning of the I/O buffer structure, the byte is written into it and the byte counter is incremented. Next round the pointer points to the second byte in the I/O buffer and so on. After 24 bytes the byte counter and thus the pointer are reset with the next byte coming in.

    Und wenn der Code dort eine Struktur aufbaut, die anschließend beim Boot-up mit Nullen überschrieben wird, wo soll da was nicht richtig gesetzt oder initialisiert sein? only if startup.a51 match your actual situation.
    As I told before, I have a function which clears the I/O buffer with zeros at startup and after every 24 bytes received.

Children
  • As you can see in the code example above
    unreadable because you did not use pre and /pre
    also, there is no indication what is int and what is char. Int used in both an ISR and main is one of the most "popular" causes of "this proven well working program fails, it can not be my code"

    As I told before, I have a function which clears the I/O buffer with zeros at startup
    What does that achieve if the pointer is wrong when the first char is written.

    Erik

  • As you can see in the code example above
    unreadable because you did not use pre and /pre
    also, there is no indication what is int and what is char. Int used in both an ISR and main is one of the most "popular" causes of "this proven well working program fails, it can not be my code"

    As I told before, I have a function which clears the I/O buffer with zeros at startup
    What does that achieve if the pointer is wrong when the first char is written.

    Erik

  • Sorry, Erik, I don't use this forum very much so I didn't remember that 'pre' thingy. But the code should be readable even on green. ;O)

    About the pointer: I'm not as stupid as I may sound, but when I set a pointer to a certain address BEFORE I write a byte into this address, the pointer can't be wrong.

    We don't speak about a mysterious device with commonly unexpected and unlogical behaviour, we speak about a microcontroller. It has to work, else it's not worth the money.