Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 3 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.
MX28
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;
timer.start();
while((timer.read_ms() < MX28_PROTOCOL_COMMAND_RESPONSE_TIMEOUT_MS) && (!isWholePacket))
{
if(servoSerialHalfDuplex->writeable())
{
switch(encoderState)
{
case WAIT_ON_HEADER_0:
{
#ifdef MX28_DEBUG
pc->printf("Write: 0x%02X ", MX28_PROTOCOL_HEADER_0);
#endif
servoSerialHalfDuplex->putc(MX28_PROTOCOL_HEADER_0);
encoderState = WAIT_ON_HEADER_1;
break;
}
case WAIT_ON_HEADER_1:
{
#ifdef MX28_DEBUG
pc->printf("0x%02X ", MX28_PROTOCOL_HEADER_1);
#endif
pc->printf("wait"); //this one prints
servoSerialHalfDuplex->putc(MX28_PROTOCOL_HEADER_1);
pc->printf("wait"); // this one doesn't
encoderState = WAIT_ON_SERVO_ID;
pc->printf("wait");
break;
}
2 Answers
7 years, 4 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) ;
LPC_UART1->THR=i;
8 years, 3 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....
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 2016That 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