Please read through this thread
Heavy use of the function “SetLCDText” is causing software written in versions 220.127.116.11 and 18.104.22.168 to stop working (perhaps earlier versions as well but it’s taking too much time to test everything). It’s a subtle problem and may not be seen for several minutes, but the issue can be reproduced with simple code constantly making calls to SetLCDText. Removing the RX connection back to the cortex seems to help but has not definitively been proven to solve the issue.
This problem has been seen on older NC2 hardware as well as newer A3 versions. Master code used for the testing was V3.20 and 3.21 but does not appear to be connected.
This code can reproduce the problem
void OperatorControl ( unsigned long ulTime )
int LoopCounter = 0;
InitLCD ( 1 ) ;
SetLCDLight ( 1 , 1 ) ;
while ( 1 ) // Insert Your RC Code Below
SetLCDText ( 1 , 1 , "%d" , LoopCounter++ ) ;
SetDigitalOutput ( 12 , LoopCounter & 1 ) ;
A repeating timer running in the background continues so the cortex has not “crashed” completely but the main loop has been blocked.
We are investigating the issue, I will send you an update as soon as we have something to report.
Any news? Could you reproduce the issue?
We have beeen able to reproduce your issue for about a week. But it took the controller running from 10-30 minutes to reproduce the error running the provided code. Then finding the issue in the library took some time, the fix will be provided in the next version of easyC.
In the mean time I would recommend inserting at least a 1ms wait, that will solve the issue. You really don’t need to update the LCD that frequently, you would be fine with even 20ms or only updating when something changes. The problem you are seeing is caused by “hammering” the serial port, causing the serial buffer to overflow.
Thanks for the update. I understand constant updating of the LCD display is not necessary under most situations, the fix I supplied to team 569C was designed to only update the LCD when the text changed and reduced activity. I am surprised that adding an additional 1mS delay helps, this is not something I had observed when debugging and had already tried various delays between calls to SetLCDText in an attempt to exacerbate or improve the issue. SetLCDText already has a 20mS wait after sending data to the serial port which is wasteful of resources, using this call has a significant impact on program performance.
When you say the serial buffer is overflowing I assume that is the RX buffer, can you give more information as to the nature of the bug, this is low bandwidth data and the STM32 should have no trouble processing this stream.
Anyway, thanks for the feedback and giving this issue some attention.
Unfortunatly I cannot provide more details, I’m just passing allong what I was told. Please send me your e-mail in a PM and I’ll send you a library to test with.