I recently obtained an Arduino Due, and I began using it in combination with my load cell. However, when I upload my code and the serial monitor begins displaying values, it will sometimes just stop altogether. It has been happening so frequently that I'm concerned that it's an issue with the Due itself. I have tried to solve the issue by just resetting the Due every time the monitor pauses, but that is only a temporary solution, and the monitor will stop a few seconds later. I am using a delay of 1 second. Does anyone have a solution to this problem? Could it be that I need to purchase another Due?
Sorry, do you have more details, e.g. your code, what do you do on UART (and how fast)?
I could imagine this:
- your program crashes and enters a HardwareFault_Handler (and loops endless there because a memory access went wrong)
- you write to fast to UART: the previous one is not send out completely when a new send is done (a "race condition")
- you send "strange" characters, e.g. control characters (e.g. 0x13) which confuses the receiver (and might stop receiving because such a CTRL-S could mean: "Pause until CTRL-Q received").
It looks too me, when it works with 1 second delay: you send too fast: the UART could not shift out the previous string, is still in progress to send the previous one when you "restart" the UART send (override the still ongoing send).
If you send very fast and very often: check on a new send if the previous one has completed.
I see what you are saying. Is it also possible that this issue could be caused by me displaying too many things? I am currently displaying mass, number of good samples after an outlier removal algorithm, and raw digital numbers.
maybe: check when sending via UART Tx if it is free. Do not "override" the UART Tx process.
Assume, that sending a lot of data (text) takes a while (slow baudrate) and UART Tx is not ready to take a new message (or has to decide what to do with the ongoing one).
"Flow Control" on UART, "back pressure".
Just one "issue": when sending faster by MCU as UART tickles out - you have to stop your MCU for a while. Even you buffer all: when sending out is slower as sending - your buffers overflow after a while and again: UART is busy still.
My hint: check if UART Tx is ready to take the next call for Tx. If you keep going and you "override" a running UART process - your device (the UART driver) might be messed up, confused (what do you mean? "should I break the still running send?").
Thank you sir
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.