Remora - Rpi Software Stepping Using External Microcontroller via SPI

After a bit more digging, I think I found the issue. The HAL module (remora.c) has two places where it calls - line 882 & 997 (develop version). This means you get two back to back SPI transactions with ~50us between them when CS is high.

As the F103 starts copying data (from the first transaction) on the rising edge of CS, it isn't complete before the second transaction starts and DMA overwrites the original data. Since the header is first, and doesn't change, it's difficult to detect an error in the modified data.

As a temporary fix, I've commented out line 882 & changed the code around 997 to:

A more robust solution is needed, but for the moment, my lathe is working well. No more jittering and no random 360 degree revolutions!

-Rafal

 

Hi Rafal, 

I'm surprised that things are working with this change. There should be two transfers, one to read the status of the board, then we calculate the new frequency commands based on the read, and then we do another transfer to write to the board with the new commands, set points and output values. The 50us between them is when the update_freq() function is run by LinuxCNC.

The header does change with each transfer, lines 863 and 955, so that the firmware in RemoraComms::processPacket() can determine what to do with the packet data. In a read the received buffer is not moved to the rxBuffer. So how is the board getting commands.... hmm

If the CS is not going low then we need to look at the spi_transfer() function, which is calling bcm2835_spi_transfernb().

 

Hi scotta,

Yep, it was one of those 'deal with the consequences later' types of changes. I'm probably lagging a cycle. I can see the headers changing as you noted.. There is definite feedback from the board. Not sure how it's working!

In any case, I was trying to find the root of the issue. Narrowed it down to the SPI link, but not the physical interface. CS is working fine - it's a DMA issue from what I can see. Correct me if I'm wrong, but there's no double buffering. When the micro starts reading data on CS rising edge, it can take some time to finish and a new SPI transaction (the second one with the write) begins. There is potentially data being read from DMA, while the DMA is writing new SPI data.

To find the issue, I put a simple data sum checksum into the spare bytes in the read and write data structures. If either the HAL component or micro notice an error in the sum, they discard the packet.

This immediately changed the behavior from occasional glitches, to no glitches but very sparse update rate (only occasional packets were getting through). After seeing the back to back SPI transactions, I thought it likely the above DMA was causing this. It still could be something else that can be 'fixed' by increasing the delay between SPI transactions.

The changes I have made to make the lathe run smoothly include keeping the checksum. There is no more noticeable data intermittency / hesitance as I am running it.

Ultimately, it'd be great to come up with a fix that retains normal functionality. Are you able to reproduce the issue I'm seeing?

-Rafal

Hi Rafal, 

A really interesting update. SPI has always been susceptible to noise on the bus and has caused issues for many people including myself. I get around this by using custom made pcb's to connect the board to the RPi or using very short ribbon cables.

Can you share your checksum implementation as this would be a great addition to Remora to make the comms more resilient to these types of issues.

For the F103, the packet processing is only done when the Chip Select rises (see line 36 in  github.com/scottalford75/Remora/blob/dev...omms/RemoraComms.cpp ) and the next DMA transfer is only enabled (line 182) after the data is moved from the temporary buffer to the rxBuffer. So maybe not related to the DMA SPI.

Hi Rafal, 

Thinking more on your post "only occasional packets were getting through". What is your hardware setup? Maybe you are getting lots of noise on your SPI wiring if you are dropping lots of packets with your checksum implementation.

sorry to interrupt with cakeslob bullshit but.... more cakeslob bullshit incoming....

Trying to setup an STM32h743, the new SKR3 uses this chip, a pretty big jump from f407 at 480hz (it looks pretty slick)

github.com/cakeslob/Remora/tree/stm32h74...areSource/Remora-OS5

I made the TARGET_STM32H7 based on the f4, with just a quick replace from f4 to h7
I made a custom target based on nucleo h743 called SKRV3, its not configured yet, but that I can mash my way through later,

github.com/cakeslob/Remora/tree/stm32h74...ARGET_STM32H7/thread

This part....I think I will need to actually change things...like.....timers and interrupts....or something....

Im using these as reference, Migration from Stm32F42x to Stm32F7, and then Migration from Stm32F7 to Stm32H743

www.st.com/resource/en/application_note/...microelectronics.pdf

www.st.com/resource/en/application_note/...microelectronics.pdf


Here is my interpretation so far

I dont really know what Im doing most of the time already, but from the looks of it, a lot of things are the same but better, but there are some different in the NVIC.

24 TIM1_BRK_TIM9 becomes TIM1_BRK
25 TIM1_UP_TIM10 becomes TIM1_UP
26 TIM1_TRG_COM_TIM11 becomes TIM1_TRG_COM


I dont know what it means, but I know its different and its in the createThreads.h so it will probably need to be changed. Am I on the right path here for porting to h7 or no?
Your patience is appreciated