Remora - Rpi Software Stepping Using External Microcontroller via SPI

Hi, the behaviour you describe is what I get when there is no SD card inserted..

but i loaded the firmware with the sd card.....
I get the same thing with no sd card also, except the led for sd-det is off. I tried reformatting it with fat and then fat32 and still nothing, how should I be formatting this, and it works with the other boards

I think the sdblock spi cs pin needs to be a software spi pin , it doesnt look like PC_9 is a hardware spi3 pin

 
but i dont understand how that last part works

Hi, the firmware is loaded by the bootloader code.

We should be able to do everything in hardware as there is no sharing of pins from what I can see in the schematic.

The same pins are used for the SKR2 SD card but in SDIO mode. I'll experiment on that board with the SDBlockDevice to try and understand what is not being configured correctly.

ok, not working yet, but closer. your patience and help is appreciated as always.
Like you said, SD card, so I read through sdblock, and theres some difference between sdsc and sdhc, so I loaded it and it can mount the file system with the sdhc. so something about my other sd card, it can load the firmware properly but no mount the file system.

So, what I have going now,
it reads the config file, finishes setup, then start, then goes into idle.
when I hit estop , in linuxcnc terminal i get bad spi payload=0 (or 32303a30 depending on what I set my spi1_clk_divsor to) and it goes back into estop.
in remora uart it reloads the setup and goes back into idle, here is the log when i hit estop here is my pinout also
 
 

I shifted the pru reset over to the next pin , which is btn_en2 aka PE_8, because the pin I would use, SPI1_DET aka PB_11 looks tied to vcap1 and since idk whats going on there, I just changed it to btn_en2.

I can't confirm until I can get into the workshop but it would appear we're missing the PC9 chip select option in the PeripheralPins.c definition in the MONSTER8 target. 

I'll need to fire up CubeMX to get the proper definition and give it a go.

Thanks for your persistence with this. The joy of being the first to try a new board out.

yeah, thats what I was trying to say with the software pin thing, I dont see it listed in the datasheet as an actual spi pin,  its an SDIO pin, but not SPI cs,  SPI3 cs is either on pin PA_15, or on PA_4 (same as spi1cs), as an alternate pin function 

I did compile a version with this change after I read about the interrupt vector table, but I didnt make a difference so I there theres more I would have had to do, or it only works on SPI1




yes, the joy of new boards I am 0/4 so far lol , I honestly though it would be easier once the framework was in place and it makes me appreciate all the hard work that went into it even more.

cakeslob wrote:

ok, not working yet, but closer. your patience and help is appreciated as always.
Like you said, SD card, so I read through sdblock, and theres some difference between sdsc and sdhc, so I loaded it and it can mount the file system with the sdhc. so something about my other sd card, it can load the firmware properly but no mount the file system.

So, what I have going now,
it reads the config file, finishes setup, then start, then goes into idle.
when I hit estop , in linuxcnc terminal i get bad spi payload=0 (or 32303a30 depending on what I set my spi1_clk_divsor to) and it goes back into estop.
in remora uart it reloads the setup and goes back into idle, here is the log when i hit estop here is my pinout also
 

File Attachment:

File Name: log.txt
File Size:3 KB

 

I shifted the pru reset over to the next pin , which is btn_en2 aka PE_8, because the pin I would use, SPI1_DET aka PB_11 looks tied to vcap1 and since idk whats going on there, I just changed it to btn_en2.

Great news that you have got this far. The SPI comms with the RPi should be straight forward now as it is using the same SPI as the SKR2 board (the board used for STM32 porting). For starters, do not connect the reset pin so as not to trigger an unwanted board reset. If the board resets after too many bad SPI packets then I would look at wiring issues. Try to use as short as practical ribbon cable for the connection between the RPi and the controller board.

cakeslob wrote:

yeah, thats what I was trying to say with the software pin thing, I dont see it listed in the datasheet as an actual spi pin,  its an SDIO pin, but not SPI cs,  SPI3 cs is either on pin PA_15, or on PA_4 (same as spi1cs), as an alternate pin function 

I did compile a version with this change after I read about the interrupt vector table, but I didnt make a difference so I there theres more I would have had to do, or it only works on SPI1

else if (this->interruptPin == PC_9)
{
// interrupt pin is not the NSS pin, ie the board shares the SPI bus with the SD card
// configure the SPI in software NSS mode and always on
sharedSPI = true;
HAL_NVIC_SetPriority(EXTI9_5_IRQn , 5, 0);


yes, the joy of new boards I am 0/4 so far lol , I honestly though it would be easier once the framework was in place and it makes me appreciate all the hard work that went into it even more.

Hmm, so how is the CS being handled then. I'll need to look into the API to see if it's rolling back to having the CS always low and software NSS configured.

The code snippet is from the RemoraComms and will have no effect on the SD SPI card config.

so, preface, Im using the same 4"/100mm cable i use for all my remora setups, but ill change over to a 2"/50mm one and see what happens. with no reset pin, it never goes idle and resets every 2 estop clicks.

for the software/hardware cs pin, i figured it would be the same as the mks robin config because looking at all the pin stuff, They both use the same spi1 for main comms , and both use SDblock with software nss, the only difference i see is robin is on spi2 and monster8 is spi3

The way you have it setup looks proper, in sdblock its using dynamic pin mode