Remora - Rpi Software Stepping Using External Microcontroller via SPI

Hi Cakeslob, 

Man, you are on the forefront. I was not even aware there was a SKR3 board out. Thanks for taking on the challenge. Just comparing the following would be a start:

I assume that we will utilise the standard bootloader. So in system_clock.c the VECT_TAB_OFFSET needs to be set to 0x20000. From the Marlin stm32h7.ini file.

For the clock configuration to achieve 480MHz

In interrupt.h change PERIPH_COUNT_IRQn to 150

For the threads, timers 9, 10 and 11 are not available in the H7. Timer 2 is used for the Mbed ticker. So createThreads.h should be able to be configured with timers 3, 4 and 5 with TIMx_IRQn interrupt sources.

timer.cpp also needs to be updated to configure the timers used for the threads.

This would be a starting point.

My first suggestion would be to get a "Hello world" working to know the clock configuration is up and going correctly.

The DMA seems to be different also which would need some looking into especially the SDIO code.

Looking forward to this board being Remora enabled. Thanks

Hi scotta,

No worries, can share the code. It was a very quick shoe horned approach. I'd expect a CRC would be much better.

F103 dev branch

Just looking at the above code, I am disabling and reenabling the interrupts which could be part of the issue / solution. I've also wrapped the timer interrupts with disable / enable irq.

It may not be DMA, just seemed the likely culprit. Noise on the SPI interface could cause the same issue as memory corruption, although I am seeing a major improvement by removing one of the SPI transactions (no change to the wiring). As the checksum is rejecting bad packets, I'd expect the same stuttering issues to be noticeable if it were a wiring problem (regardless of if there is one or two SPI transactions back to back).

I have a fairly tightly coupled system with the RPI and F103 board back to back. Yes, wiring could be the issue - although based on the above, something else is likely occurring.

My mill has an SKR1.3. I've been meaning to upgrade it to an RPI / Remora. I could test with similar wiring and confirm it is isolated to the F103 code for me. It's a big job, so I may temporarily test it out.

Hmm. Considering your comment about DMA being enabled only at the end of the CS high interrupt - could there be some interaction where the DMA is enabled mid second SPI transaction (CS could have gone low while we were processing) and then giving some useless data (let's ignore the header check for the moment)?

I'm curious as to whether we've got a similar issue that was a bug in the Remora-NVEM version where the data move was being interrupted and corrupted by the threads. It was fixed by disabling interrupts before moving the data.

Doing the same in RemoraComms.cpp at lines 165 may do the trick.

Looks like I've come to a similar conclusion - as that's what I've done in my repo.

Just tested keeping everything the same and re-enabling the other SPI comms in the LinuxCNC component yep, that looks to have been it. I probably tested those two changes together. Rookie mistake!

Great to hear. Something to fix in not only the F1 version, but also there in the F4. Thanks for your persistence and help!!

Good news on the H7 , kinda got it working with hello world. It works enough to print hello world, then prints an mbed error about the clock something (the error code is error unknown), but that is minor details probably
github.com/cakeslob/Remora/blob/hello-wo.../Remora-OS5/main.cpp

I dont know what this is, but its prints -0

Anyways, first problem, mbed will not net me compile Stm32H743VI with a bootloader. It says unsupported, dont know what to do about that aside from not use the bootloader for now.

second, the SDIO looks really hard. According to the migration guides, F4 to F7 there is a big difference, but from F7 to H7 theres just a interrupt vector change (as far as I can tell), so maybe jojos F7 sdio will work with minor changes

The DMA looks like theres a big change, will that mostly be found in the comms area? Only thing I know about the dma is that dma is good for remora, and that there is an interrupt vector called mdma, and i giggled.

The rest seems more clear after going over the migration guides and Im just changing thing to timer 3 4 and 5, but Im stuck at a part. with timer.cpp , the presence of TIM3 on APB2CLK has me stuck......do I just leave this and change the rest?

Hi cakeslob, great to hear that things are slowly moving forward.

I'm guessing you have made a new target in custom_targets.json, adding  "bootloader_supported": true as an options should allow it to compile. I'll need to set one up to see.

Timers 3,4 and 5 area all on AHB1/APB1 according to the bus diagram.

I'll need to look at the DMA as there is MDMA and DMA controllers. Hopefully using the DMA controller will not mean to many changes needed.

Once I'm finished with the Remora-EC500 code, I'll need to get one of these boards to try and help out.

A very generous forum member sent me an SKR3 for development. Thanks so much to them!!!

The STM32H743 used on the board is a beast and a step above in features and capability, which also brings some complexity and a steep learning curve to get this up and running.

I'll be calling on anyone with H743 experience to help out with this one.

First step - getting a "Hello world" working.

1. STM32CubeIDE: working with and without bootloader
2. Mbed: working without bootloader but hard faulting with bootloader

Step two - getting the SD card working with the SDMMC interface. This is probably the biggest challenge.

@JojoS your Mbed SDIO for the F4 worked a treat. Hoping your experience might help here for the H7? Attempts with STM32CubeIDE have failed to get the SD to mount.

I have now a version that compiles (very dirty) for H7, but is not yet working. The DMA stuff is really completely different. But I'm hopeful

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

update:
I have created a branch for the H7 in my github repo github.com/JojoS62/COMPONENT_SDIO/tree/add-h7-sdio
Status is still not working ;(
The DMA for the H7 should be easier if not the highest speed modes are used. The SDMMC has a dedicated DMA, called IDMA. This does not need configuration like the general DMA channels on the other MCUs.So everything should be easier.
Calling sd.init() is returning success and the SD info about size is correct. But reading a sector with DMA fails with timeout. I have an IRQ handler for the SDMMC1 irq (yet fixed to SDMMC1) and this is never called.
Tried also a lot of different clock speeds and settings for SDC Init, nothing worked. There is a similar use case in betaflight sofware, it looks really similiar.
And also reading blocks without DMA fails, so something wrong after switching to 4 bit mode.

some good news: the version in my repo is now working roughly.I haven't added the cache flushes yet, that is necessary when D-Cache is enabled. In my test app I have disabled the DCache and I can read my SD cards. The proper code needs some more work. For reading, the cache flush is needed after reading operation. But this is an async operation with DMA, so the DMA complete has to know the readbuffer address and size.
The strange trick was to enable the `hsd.Init.ClockPowerSave = SDMMC_CLOCK_POWER_SAVE_ENABLE;` I haven't figured out why, but when it is disabled like in other examples, no interrupts were fired.

Another strange (Mbed) thing is the SLEEP feature. It uses __WFI to bring the MCU to sleep mode during ThisThread::sleep_for(). But this detaches the debugger and so I like to disable or remove this feature. When I remove SLEEP, then the SD Component fails again. With SLEEP component and locking the sleep manager, SD works, but restarting the programm works only in a few times. Ok, that may be some Mbed problem.

Tomorrow the arrival of the SKR3 is expected and I can test also with the correct target hardware.