Motors do not configure but UART OK.

[Short-bus]

There's a case where the UART communication log on the RPi looks OK. There are SEND and RECEIVE messages being logged between the RPi and the microcontroller. However the messages coming back from the microcontroller suggest that the RPi messages are not being handled properly by the microcontroller. eg: Motor configurations are sent, but the returned motor status does not show that the configuration has been set. eg: The 'set time' message is sent to the microcontroller, but the microcontroller messages do not show the synchronised time in the example messages seen. Is there a way to identify what is causing the problem?

Full log file probably needs checking for other error messages. Microcontroller could be hooked up to UART & USB so it can be monitored through the SHELL window in Thonny.

Original message:

Troubleshooting help

 'Motor Tools' > 'Tune Azimuth' > '1000' > Enter

motorcontroller.TunePosition( azimuth ): Motor is not yet configured. Tune command will not be sent.

Tiny 2040 LED does light up prior to running the adjustment.

Motors do not move at all

Checked soldering, no change, can anybody cypher the log?

received:   motor status 20200101000016 azimuth n 20200101000016 0 48000 180.0 n n 0.1 2464 tmr      
queueing   (Q# 1): configure motor 20240203171249 azimuth 180.0 0 360 0.0 -1 0.001 0.05 0.003 10 [14]      
received:   motor status 20200101000016 altitude n 20200101000016 000.0nn0.1 3024 tmr      
queueing   (Q# 2): configure motor 20240203171249 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [15]      
received:   log :20200101000017:CPU UID: df-60-9c-80-67-2b-45-28 Core: 0, ResetReason: POWER_ON, Temp:   -92.2365, Freq: 125M, Volt:   3.3
received:   log :20200101000017:CPU UID: df-60-9c-80-67-2b-45-28 Core: 1, ResetReason: POWER_ON, Temp:   -92.7046, Freq: 125M, volt:   3.3
queueing   (Q# 1): # heartbeat [16]      
received:   motor status 20200101000026 azimuth n 20200101000026 0 48000 180.0 n n 0.1 2400 tmr      
queueing   (Q# 1): configure motor 20240203171259 azimuth 180.0 0 360 0.0 -1 0.001 0.05 0.003 10 [17]      
received:   motor status 20200101000026 altitude n 20200101000026 000.0nn0.1 2992 tmr      
queueing   (Q# 2): configure motor 20240203171259 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [18]      
received:   session status 20200101000033 n n n 27 0 tmr      
queueing   (Q# 1): set time 20240203171306 [19]      
received:   comms status 20200101000033 0 1 1224 0 26696 0 1 tmr      
received:   motor status 20200101000036 azimuth n 20200101000036 0 48000 180.0 n n 0.1 2752 tmr      
queueing   (Q# 1): configure motor 20240203171309 azimuth 180.0 0 360 0.0 -1 0.001 0.05 0.003 10 [20]      
received:   motor status 20200101000036 altitude n 20200101000036 000.0nn0.1 3680 tmr      
queueing   (Q# 2): configure motor 20240203171309 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [21]      
received:   motor status 20200101000046 azimuth n 20200101000046 0 48000 180.0 n n 0.1 2176 tmr      
queueing   (Q# 1): configure motor 20240203171319 azimuth 180.0 0 360 0.0 -1 0.001 0.05 0.003 10 [22]      
received:   motor status 20200101000046 altitude n 20200101000046 000.0nn0.1 2944 tmr      
queueing   (Q# 2): configure motor 20240203171319 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [23]      
received:   session status 20200101000053 n n n 47 0 tmr      
queueing   (Q# 1): set time 20240203171326 [24]      
queueing   (Q# 2): # heartbeat [25]      
received:   comms status 20200101000053 0 1 1678 0 46699 0 1 tmr      
received:   motor status 20200101000056 azimuth n 20200101000056 0 48000 180.0 n n 0.1 2560 tmr      
queueing   (Q# 1): configure motor 20240203171329 azimuth 180.0 0 360 0.0 -1 0.001 0.05 0.003 10 [26]      
received:   motor status 20200101000056 altitude n 20200101000056 000.0nn0.1 2528 tmr      
queueing   (Q# 2): configure motor 20240203171329 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [27]  

[Short-bus]

received:   motor status 20200101000016 altitude n 20200101000016 000.0nn0.1 3024 tmr      
queueing   (Q# 2): configure motor 20240203171249 altitude 0.0 0 90 0.0 -1 0.001 0.05 0.003 10 [15]  

The above exchange shows that the RPi is receiving and understanding the microcontroller. The motorcontroller is sending motor status, the RPi understands this is an unconfigured motor so responds immediately with a configuration message. However all the followon status messages from the microcontroller continue to show an unconfigured motor, this suggests that the microcontroller is not receiving or processing the messages from the RPi properly.

The motor status messages include the 'tmr' status code, this indicates WHY the status message was sent. In the log file these are ALL 'tmr' which means the message is just a timed message. If the microcontroller was processing the configure motor messages correctly it responds immediately with a 'cfg' code instead of 'tmr'. This also suggests that the microcontroller is not actually processing the messages.

received:   session status 20200101000053 n n n 47 0 tmr      
queueing   (Q# 1): set time 20240203171326 [24]   

The above exchange shows a session status message from the microcontroller, it includes a timestamp - the timestamp is the default 2020.Jan.01 00:00:00 clock. The RPi responds with a 'set time' message to set the clock to the current time. However all the later messages from the microcontroller continue to show the unsynchronised clock. This also suggests that the microcontroller is not receiving or processing the messages.

If the microcontroller was completely crashing we would not receive any further messages. If the microcontroller was failing and restarting we would see repeated blocks of messages identifying a restart. Neither is occurring, so the problem is likely to be a non-fatal fault in the microcontroller processing. The most likely reasons being a break in the TX->RX line from the RPi to the microcontroller, or a function call failing on the microcontroller.

To see the precise detail the microcontroller was connected via a USB cable to the RPi and the serial shell output viewed through Thonny. It then was apparent that the microcontroller was running the wrong version of CircuitPython.

The code currently only works on CircuitPython7, the microcontroller was running CircuitPython8 which has syntax changes in the UART module. Downgrading the microcontroller to CircuitPython7.2 should solve the problem.

When the microcontroller first starts communicating it should pass information about the environment including some CircuitPython version information. This will be visible in the RPi log file, you can also trigger this to be resent by pressing the 'reset' button on the microcontroller to trigger a restart.

Later versions of the software compare the reported version number against a list of supported versions and leave a warning in the log file too.

[Short-bus]

The 2024-01-issues branch includes an updated version of circuitpython/code.py which now also runs on CircuitPython8.

[Short-bus]

Done.