Cannot obtain settings or system info through MPG uart on STM32F407

[AvatarBg111]

I'm working on a project, which is to implement a system for controlling a CNC mill. I'm using a STM32H750 to act as a gauntlet controller and a STM32F407 for the GRBL firmware. The two microcontrollers are connected via UART. Right now I'm trying to obtain the settings and system info of the STM32F407 by sending $$ and $I from the STM32H750. I hooked up a logic analyzer on the UART pins and I'm seeing that the STM32H750 is sending the mentioned commands, but the STm32F407 does not respond... Meanwhile, when the STM32F407 is connected via USB to ioSender on my computer and i send a $$ message through the terminal i receive the settings. What could be the cause for this case?

[terjeio]

The F407 UART is not configured for use? grblHAL only accepts high-level input from one stream at a time, if multiple UART streams are to be used stream switching is needed. Currently this is either via a dedicated pin or via a real-time command character. Either way the second UART has to be put in MPG mode first.

Yesterday I added a new MPG mode that does not require the keypad plugin making it somewhat simpler. To switch the imput stream to the second UART port send the 0x8B real-time command character. If the switch is accepted MPG:1 will be added to the real-time report (automatically sent) and you can then send $$ to get the settings. Send another 0x8B character to give back control to the original input.

[AvatarBg111]

Hello. I'm sorry I didn't reply to your comment sooner. I've configured the firmware to use SERIAL_MOD for MPG. I've set SERIAL_MOD to 3 (UART pins are PD8 and PD9), MPG_ENABLE to 1 and KEYPAD_ENABLE to 2. When testing to see if the STM32F407 would respond to "$$", i though of trying to first enable MPG with 0x8B command. After enabling it I sent "$$", but i didn't receive a response. I'm not sure if it will fix something, but I'll try to load the newest version of grblHAL in to the microcontroller, since the version I'm using is I think "230807".

[terjeio]

How do you send the 0x8B character? And did you get a real-time report following it with the MPG:1 element in it?

[AvatarBg111]

I do send it. I did get a response with MPG:1. Here are some crude screenshots:

[AvatarBg111]

Here's the code that does this:

void grblGetSettings(void){ //grbl_settings_received_ptr on_settings_received

if(0)

if(grbl_data.mpgMode && grbl_event.on_line_received == parseData){
    grbl_event.on_settings_received = on_settings_received;
    grbl_event.on_line_received = parse_settings;
    serial_RxCancel();
    serial_writeLn("$$");
}else if(on_settings_received){
    on_settings_received(&settings); // return default values
}

else

uint8_t mpg_enable = 0x8B;
HAL_UART_Transmit(&huart2, &mpg_enable, 1, 5);
while(grbl_data.mpgMode == false){
    char test_str[15] = {0};
    sprintf(test_str, "MPG mode: %d", grbl_data.mpgMode);
    HAL_UART_Transmit(&huart4, (uint8_t*)test_str, strlen(test_str), 5);
    delay_ms(10);
}
HAL_UART_Transmit(&huart2, (uint8_t*)"$$", 2, 5);

endif

}

[terjeio]

Your code seems to be ok. A tip for debugging is to change the mode switching character to one easily available from the keyboard, if you have a USB <> UART breakout you can then simulate the MPG from a terminal. I just did it by changing it to '&' here - and testing shows it works, at least with the latest version I have. Top window is the main input stream, bottom is the MPG stream:

[AvatarBg111]

Yesterday, I tried to upload the new version of the grblHAL firmware into the STM32F407, but when compiling there were some errors that came up. The compiler couldn't find some structures (to be exact, they are "pin_cap_t" and "aux_ctrl_t").

[AvatarBg111]

I found the problem with compiling the project. When I cloned the repository with grblHAL for STM32F4xx and placed all it's contents in my STM32CubeIDE project, some files from the old version of the firmware remained inside the project.

[AvatarBg111]

I loaded the new firmware and tried sending g-code for movement of the machine, but i still didn't receive any response. Here are some screenshots:

Could the issue be that the UART stream's reception functionality has been turned off (and the microcontroller responds to 0x8B only because that command is parsed by the KEYBOARD plugin)?

[terjeio]

Could the issue be that the UART stream's reception functionality has been turned off (and the microcontroller responds to 0x8B only because that command is parsed by the KEYBOARD plugin)?

I do not think so. You are using USB_CDC (= "native" USB) for the main connection?

Can you try with MPG_ENABLE 2 and KEYPAD_ENABLE commented out? This removes the keypad plugin from the equation.

[AvatarBg111]

I am using USB_CDC for the main connection. I'll try what you suggested.

[AvatarBg111]

I tried what you suggested, but to no avail. The same thing happens. Just to be sure I'm not doing something incorrectly, I'm going to tell you what I'm doing when testing this: 1) Load the firmware into STM32F407 2) Connect STM32F407 to computer via USB (USB_CDC communication) 3) Start recording UART communication with my Logic app (the one for the digital analyzer that is tapping the TX and RX lines of the UART port between the two microcontrollers) 4) Startup ioSender (when the connection between the app and STM32F407 is established, I immediately see the GRBL auto reports in the Logic app) 5) Call the function grblGetSetting() in the program of STM32H750 microcontroller

[terjeio]

I have now tested the same configuration as you have with a Nucleo-F446ZE board and it works for me. $pins report the UART like this:

...
[PIN:PD9,RX,MPG]
[PIN:PD8,TX,MPG]
...

Note I did change 0x8B to '&' as described above so I could test with a terminal.

Which board do you use?

[AvatarBg111]

The STM32F407 microcontroller's board is DevEBox V3.0 (uses stm32f407vgt6 chip) https://github.com/mcauser/MCUDEV_DEVEBOX_F407VGT6

[terjeio]

Startup ioSender (when the connection between the app and STM32F407 is established, I immediately see the GRBL auto reports in the Logic app)

When you send 0x8B is the ioSender UI greyed out? And do you have access to a USB <> UART breakout? E.g. a Pi Pico debug probe can be used as one. Are you programming the F407 with a debugger and can set breakpoints?

[AvatarBg111]

ioSender's UI does become gray after sending the 0x8B command on the UART port. I don't have a breaout board for USB<->UART translation. I program the STM32F407 microcontroller via a SWD port with a J-Link programmer device. I can use it for debugging, but how would that help?

The two microcontrollers are connected to a custom breakout board that I've designed. The UART connection between them is correct and I've checked it a couple of times. Here's a picture of the board:

There are two circles in the picture, which show the USB ports (they're not very visible, because they're on the other side of the development boards of the microcontrollers). The yellow circle shows where's the USB port of the dev board of the STM32F407 and the purple circle shows where's the USB port of the dev board of the STM32H750.

The STM32H750 microcontroller's development board is made by WeActStudio (and it uses STM32H750VBT6 chip): https://github.com/WeActStudio/MiniSTM32H7xx

[terjeio]

Set a breakpoint here, this should be hit regularly after sending 0x8B as the main loop will start polling for input. Is it?

If it is disable it and set another here, if possible after 0x8B is sent but before $$ is (add a delay in the H750?). It should be hit for each character received. Are the $ characters arriving?

[terjeio]

Oops, I forgot the obvious one - you have to add a line termination character to $$, either a carriage return or a linefeed. - e.g. "$$\n" Sorry about that...

[AvatarBg111]

Eureka! I just tried what you suggested and you are totally correct! I added "\n" after "$" and received a report on the UART port. To be honest, I think it was two days ago, I thought of a simmilar solution, but instead I tried "$\r\n" and received "error:2", which made me think that "$\n" or "$\r" would end up with the same result... Again, thank you very much for the support!