7 years, 7 months ago.

Problem with serial putc

Hey, I have three LPC1718's connected to Dynamixel actuators, and I am using the MX-28 library that is available for mbed. I was able to use the library without a problem for some time, until it simply stopped working with 2 of the boards. That happens when calling any function of the library which involves sending a packet to the actuator via the serial connection. I have traced the problem to be in the putc function of the SerialHalfDuplex library, which seems to call on the putc of the Serial library. I don't understand why is it that the same code is working on one of the boards but not on the other 2, while they are all configured in the same way with the same connections. Could there be a flush problem or something of the sort on the serial? Turning it all on and off does not make a difference, so it should be something stored in memory.


uint8_t MX28::CommunicatePacket(MX28_PROTOCOL_PACKET *packet)
    uint8_t currentParameter = 0;
    bool isWholePacket = false;    
    uint8_t encoderState = WAIT_ON_HEADER_0;
    packet->checkSum = Utilities::GetCheckSum((uint8_t*)&(packet->servoId), packet->length + 1);

    Timer timer;
    while((timer.read_ms() < MX28_PROTOCOL_COMMAND_RESPONSE_TIMEOUT_MS) && (!isWholePacket))
                case WAIT_ON_HEADER_0:
                    #ifdef MX28_DEBUG
                        pc->printf("Write: 0x%02X ", MX28_PROTOCOL_HEADER_0);
                    encoderState = WAIT_ON_HEADER_1;                
                case WAIT_ON_HEADER_1:
                    #ifdef MX28_DEBUG
                        pc->printf("0x%02X ", MX28_PROTOCOL_HEADER_1);
                          pc->printf("wait"); //this one prints
                    pc->printf("wait"); // this one doesn't
                    encoderState = WAIT_ON_SERVO_ID;

If you are seeing different behavior with the same code on the same model boards then that points to a hardware problem. Can you use a scope to look directly at teh mbed pin and check whether the data is coming out? Any danger of the servos damaging toe IO ports in any way? I have an LPC1768 where one of the UARTs stopped working, I put that down to ESD damage.

posted by Andy A 05 Aug 2016

That could very well be the cause, maybe the servos damaged the IO ports. But why would it hang on the second putc instead of the first one? I will try to use the scope.

posted by Arthur Araujo 05 Aug 2016

2 Answers

6 years, 7 months ago.

i might have the same problem. Using the LPC1768 for some time i got a system halt the moment the putc is done in the code. This is on all 3 LPCs i used. Strangly it depends on the amount of data send. The system halt is random. Can be after 20000 dumps, or after 400. Changing the UART doesnt solve it. I'm not using the RTOS as the application is timecritical.

It might be solved by using a direct call to the UART Running this code instead of Putc the system doesnt halt now for days. More testing will be done

   do {
            } while ((LPC_UART1->LSR & 0x20)==0) ;

7 years, 6 months ago.

Interesting...I am seeing a similar problem with serial on ST Nucleo. Something has changed recently. I have a suspicion the compiler version changed and it's a problem there. I am waiting on an answer for my issue as well....

The strangest thing is that the same file is being used on the three boards, and it only works on one, so I am not sure if it's because of the compilation...

posted by Arthur Araujo 04 Aug 2016