MKS-Robin-Nano-V3.0 support

[qbazd]

Hi,

I have board MKS-Robin-Nano-V3.0 (https://github.com/makerbase-mks/MKS-Robin-Nano-V3.X) lying around and trying to port grblHAL to it. I have couple CNC mashines would like to unify their setups to OpenSource toolsets. Using BluePil F103 for now but with somewhat very patchy setup.

I've tried to base my work on btt_skr_2_tmc2130 (same uC).

My modifications for development are:

• get rid of bootloader (back with base to 0x8000000)
• get blinking led PD_12 (SD_DET in mks schematic) to check if soft it's starting.

I'm stuck on USB CDC - enumeration for start, communication would be right thing.

My approach was first to test with very hello world example of other code. I've have successfully made and uploaded USB CDC example using stm32 arduino (board have to be OK).

[env:test_f407vgt6]
platform = ststm32
framework = arduino
board = genericSTM32F407VGT6
board_build.f_cpu = 168000000L
board_hardware.oscillator = 8000000L
build_flags = -D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC

#include <Arduino.h>
int i = 0;
void setup() { Serial.begin(115200);}
void loop() { Serial.println(i++); delay(250); }

When but I have failed with doing the same with Platformio+CubeMX. As the my experience with low level ARM is on my bucket list for now.

My question is: How to start overcoming this issue and start digging in right direction? I have feeling that clock initiation and peripheral setup plays key role here. ;)

All the best Jakub

[terjeio]

I have feeling that clock initiation and peripheral setup plays key role here.

It does, especially for USB comms - the clock supplied to the USB peripheral has to be within tolerances. Note that the default crystal frequency is 25 MHz, this board has a 8MHz crystal - you may try with setting the HSE_VALUE symbol to 8000000.

The clock tree is set up in main.c - if changing the HSE_VALUE does not help other values migh need changes as well.

[qbazd]

btt_skr_2_tmc2130 have same same uC and HSE_VALUE (8MHz). That was exactly my point while selecting the code base for plying around. And exactly my idea to start with simple example on board. -D HSE_VALUE=8000000L

I belive this is the code what use HSE_VALUE:

#elif defined(STM32F407xx)

    /** Configure the main internal regulator output voltage  */
   __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

    RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
    RCC_OscInitStruct.HSEState = RCC_HSE_ON;
    RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
    RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
    RCC_OscInitStruct.PLL.PLLM = (uint32_t)HSE_VALUE / 1000000UL;
    RCC_OscInitStruct.PLL.PLLN = 336;
    RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
    RCC_OscInitStruct.PLL.PLLQ = 7;

    #define FLASH_LATENCY FLASH_LATENCY_5
    #define APB1CLKDIV RCC_HCLK_DIV4
    #define APB2CLKDIV RCC_HCLK_DIV2

#else // STM32F401

Found a formula in ArduinoStm32 core:

    /* 
       PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N
       SYSCLK = PLL_VCO / PLL_P
     */

And it maches calculation with HSE_VALUE.

I'm running blink 1sec and seams to be OK.

Still stuck on no enumeration between OS on PC and device.

[terjeio]

It seems the clock tree config is correct.

However, looking at the schematic page 8: it seems PA14/USB_CTRL has to be pulled low (or high?) to enable USB?

Note that PA14 has to be reassigned as it defaults to SW_CLK on reset (used for programming/debugging). It seems both JTAG-DP and SW-DP must be disabled to use it as an output. This can be done by selecting AF0 for PA14?

[qbazd]

That was my concern also.

And I have made modifications for updating the PA14 specificity after MX_GPIO_Init in main.c.

Like this:

   #define USB_PIN 14
   #define USB_GPIO_PORT GPIOA
    GPIO_InitStruct.Pin = USB_PIN;
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
    GPIO_InitStruct.Pull = GPIO_PULLUP;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    HAL_GPIO_Init(USB_GPIO_PORT, &GPIO_InitStruct);

    HAL_GPIO_WritePin(USB_GPIO_PORT, USB_PIN, 1);

Still ArduinoStm32 example, works without any hassle.

[terjeio]

Can you measure the voltage on D+/R40 in both scenarioes (Arduino and grblHAL)?

FYI last time I checked USB comms with a F411 it was ok - can check again to be sure.

[qbazd]

I hope, I'll do it till the end of the week. I have moved whole gear to the workshop. Will try to learn more till then.

[noahwilliamsson]

Since you mentioned that you removed the original boot loader, do you upload via STLink now?

I'm wondering if it would work with something like this in platformio.ini:

[env:robin_nano_v3]
board = genericSTM32F407VGT6
board_build.ldscript = STM32F407VGTX_FLASH.ld
build_flags = ${common.build_flags}
  # See Inc/my_machine.h for options
  #-D BOARD_ROBIN_NANO_V3=
  # 8MHz crystal
  -D HSE_VALUE=25000000
  # Boot loader offset (48K)
  #-D VECT_TAB_OFFSET=0xc000
lib_deps = ${common.lib_deps}
  eeprom
lib_extra_dirs = ${common.lib_extra_dirs}

(I'm haven't looked into how the EEPROM stuff is handled on this board or what kind of support there is for it in grblHAL)

..and a modification to https://github.com/grblHAL/STM32F4xx/blob/master/Src/main.c#L42 to make it read:

MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 128K
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 1024K
}

Just below in the linker script, there's a block that looks like this:

SECTIONS
{
  /* The startup code into "FLASH" Rom type memory */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

This will place the reset vector at the start of the flash, right where the CPU will start executing after a reset.

You can verify that it actually ends up at 0x8000000 with:

objdump -h .pio/build/robin_nano_v3/firmware.elf

(also of interest: SCB->VTOR elsewhere in the STM32CubeMX code also needs to point to where ever the reset vector is; beware that there are multiple files where this is set and that you need the most recent version of PlatformIO to have a chance of overriding it with PlatformIO.)

Assuming that works, then you should be able to toggle a LED after clocks and GPIOs are setup: https://github.com/grblHAL/STM32F4xx/blob/master/Src/main.c#L42

If that also works, then maybe you can try adding the same code to somewhere before or after the driver_init() call in grbl_enter().

I didn't read this thread carefully so maybe you already did all of this and is just stuck on USB being down?

If so, I have a vague memory of attempting to set PA14 to zero (not one) on some other board (one of the BigTreeTech SKRs) -- but I don't remember if that fixed the USB issue for me or not. Your code looks similar to the one I used so I suppose it should be just a matter of changing to HAL_GPIO_WritePin(..., 0).

Do you have a complete pin mapping file and driver file for this board?

[terjeio]

(I'm haven't looked into how the EEPROM stuff is handled on this board or what kind of support there is for it in grblHAL)

There is support via plugins. The driver only has to provide a low level API for it. For this board define I2C_PORT 1,I2C1_ALT_PINMAP and EEPROM_ENABLE 3 if I am not mistaken.

[qbazd]

Done the .ld script modification already to:

/* Memories definition */
MEMORY
{
  RAM    (xrw)    : ORIGIN = 0x20000000,   LENGTH = 128K
  FLASH    (rx)    : ORIGIN = 0x8000000,   LENGTH = 512K
  EEPROM_EMUL(xrw)      : ORIGIN = 0x8080000,   LENGTH = 16K
}

And tried OneLED debug magic and but have to make it more logically consistent. I thing I'll just grab logic analyser and the scope to stop fooling around ;)

Program runs to lit a LED at some point and that was my first point to resolve.

[qbazd]

For the record:

objdump -h firmware.elf 

firmware.elf:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .isr_vector   00000188  08000000  08000000  00010000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00016658  08000190  08000190  00010190  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       000065c0  080167e8  080167e8  000267e8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .ARM.extab    00000000  0801cda8  0801cda8  00030440  2**0
                  CONTENTS
  4 .ARM          00000008  0801cda8  0801cda8  0002cda8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .preinit_array 00000000  0801cdb0  0801cdb0  00030440  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .init_array   00000004  0801cdb0  0801cdb0  0002cdb0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .fini_array   00000004  0801cdb4  0801cdb4  0002cdb4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data         00000440  20000000  0801cdb8  00030000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .bss          00004628  20000440  0801d1f8  00030440  2**2
                  ALLOC
 10 ._user_heap_stack 00004000  20004a68  0801d1f8  00034a68  2**0
                  ALLOC
 11 .ARM.attributes 0000002a  00000000  00000000  00030440  2**0
                  CONTENTS, READONLY
 12 .comment      0000007e  00000000  00000000  0003046a  2**0
                  CONTENTS, READONLY
 13 .debug_frame  000014d8  00000000  00000000  000304e8  2**2
                  CONTENTS, READONLY, DEBUGGING, OCTETS

[terjeio]

USB comms is ok with my 411 based Blackpill.

Do you have a UART <> USB breakout available? If disabling USB comms you can hook one up to the WiFi RX/TX pins to check if grblHAL is alive.

[qbazd]

Current developments:

1. UART - helped - nothing like debug console - always works
2. -D EEPROM_ENABLE=3 - did the job - turned out software frozen in https://github.com/grblHAL/core/blob/384fda6e3a135f6db1050f55a24e93260528111f/grbllib.c#L152
3. And then, USB CDC suddenly also works

I'll now invest time in correct GPIO mapping and testing facilities. Many thanks for help. I made a fork with branch for this board. Will get back to you with more problems probably or working code.

BTW, just realized 3d printer boards are very nice development boards ;)

[qbazd]

Just pushed preliminary working version to https://github.com/qbazd/STM32F4xx/tree/mks_robin_nano_v3_0 I've tested it with logic analyser and UGS, seams to be working OK...

Except for one error:

Src/driver.c:100:2: error: #error Interrupt enabled input pins must have unique pin numbers!

I understand outline of problem. But haven't wrap my mind around it yet.

[noahwilliamsson]

It says you can't have interrupts on e.g. both PA14 and PB14 because the external interrupt line for a given pin number is shared among all of the GPIO ports.

See the picture in this thread: https://community.st.com/s/question/0D50X00009XkZsL/nvic-interrupts-on-two-ports-with-same-pin-number

[qbazd]

Got it, Done, Tnx :)

[bullestock]

@qbazd is this supposed to work with copying the firmware.bin file to an USB disk? It seems to work, as the file gets renamed to firmware.cur, but afterwards I don't see any USB devices when connecting the card.

[qbazd]

Hi,

I can't remember. Have been working on that long time ago.

Sorry, All the best, Jakub

sob., 21 paź 2023 o 21:50 Torsten Martinsen @.***> napisał(a):

@qbazd https://github.com/qbazd is this supposed to work with copying the firmware.bin file to an USB disk? It seems to work, as the file gets renamed to firmware.cur, but afterwards I don't see any USB devices when connecting the card.

— Reply to this email directly, view it on GitHub https://github.com/grblHAL/STM32F4xx/issues/29#issuecomment-1773907061, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH4OKEQZ5ENKQF32BQINVTYAQRSDAVCNFSM5DEFV542U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGM4TANZQGYYQ . You are receiving this because you were mentioned.Message ID: @.***>

[terjeio]

@bullestock Are you building with a linker script that allows for the bootloader?

[bullestock]

@bullestock Are you building with a linker script that allows for the bootloader?

Uh, no idea really, I just used the existing platformio target.

[terjeio]

@bullestock Can you try this: firmware.zip

If I can get a build verified then I'll add the board to the Web Builder.

[bullestock]

@terjeio Unfortunately, that gives me the same result as with the one I built myself.

[terjeio]

@bullestock Ok, here are two more that assumes a 48K bootloader.

firmware 48K.zip

One (firmware0.bin) sets PA14 low on startup. Are you able to measure the voltage on R63 on the end that is connected to the gate of Q6, the <USB_CTRL> signal if none works? We can use this to determine if the bootloader is starting grblHAL.

[bullestock]

@terjeio I tried firmware1.bin first, and it works - I get a ttyACM0 device, and can enter grbl commands. Thanks a lot!

[terjeio]

@bullestock Great - thanks for reporting back. I'll add the neccessary details in the next commit.

[bullestock]

@terjeio any news on this? Let me know if I can help in any way.

[terjeio]

Here is the loader script I used if that helps: STM32F407VGTX_BL48K_FLASH.zip

I am not yet ready to commit the change since I am currently away and not able to properly verify a bunch of other pending changes until I am back home.

[terjeio]

Changes were commited last week.