STM32F303CCT6 (Blue Pill compatible pins) Support?

[gitxmax]

Seen this Robotdyn STM32F303CCT6 board Today, on another forum. Some serious features for $5. Twise the speed of the blue pill and more. https://robotdyn.com/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html Planning to get one, for a telescope control board, hw about running grblHAl on it?

[terjeio]

Planning to get one, for a telescope control board, hw about running grblHAl on it?

Should be doable, do you want to try to write a driver? Perhaps the STM32F4xx driver will just work after setting up the system clocks correctly? FYI the F4xx driver was close copy of the F103.

[gitxmax]

Wish I could help, but my skills are go as far as compiling the code :)

[terjeio]

Send me one and I write the driver then?

If it is really pin compatible with F103 Red/Bluepills then that driver could be retired. I have a F411 Blackpill but that is sadly not pin compatible.

[terjeio]

I now have a working basic driver for the F303, remaining is test of I2C support for EEPROM/FRAM and keypad.

The F303 is pin number compatible with the F103 but not pin function compatible. The only significant difference for grblHAL is that I2C and UART pins are swapped, boards routed to use both I2C and a UART will not work. Those that are only using a UART can still be made to work - I'll have to add code for that.

[S2000Stefan]

Hello terjeio, i have just installed the new driver for the STM32F303CCT6 with the original settings. The first time I compiled the firmware, I got a warning, but the compilation went through.

../USB_DEVICE/App/usbd_cdc_if.c: In function 'CDC_Receive_FS': ../USB_DEVICE/App/usbd_cdc_if.c:263:3: warning: implicit declaration of function 'usbBufferInput' [-Wimplicit-function-declaration] usbBufferInput(Buf, *Len); ^~~~~~ . . . Finished building: GRBL Driver STM32F303.bin Finished building: GRBL Driver STM32F303.hex

Finished building: GRBL Driver STM32F303.list

18:34:58 Build Finished. 0 errors, 1 warnings. (took 5s.84ms)

The firmware also works so far. Unfortunately, I have to report that something went wrong with the pin mapping. e.g. PB12 ->Z Limit on generic.map.h ->X Limit PB13 -> Probe -> Y Limit PB14 -> Hold -> Z Limit PB15 -> Start -> A Limit i have not checked the pins any further.

Also, changing the pin assignment in generic.map.h has no effect. For my breakout board I have to set the probe pin to PB9, for example, no change in the compiled firmware.

Notably routing I2C2 SDA/SCL signals to PB10/PB11 is not possible.

From the readme, do I understand correctly that I can no longer connect an eeprom to these pins? Or how is that meant? As you know, I am not an electronics engineer. ;-)

[terjeio]

The first time I compiled the firmware, I got a warning, but the compilation went through.

Oh, I have missed that, no big deal for now.

You use _genericmap.h for the F103? I have left BOARD_CNC3040 uncommented in _mymachine.h, could that be the reason? Change it to a comment again to use generic_map.h: //#define BOARD_CNC3040

From the readme, do I understand correctly that I can no longer connect an eeprom to these pins?

Correct, luckily the EEPROM and the UART breakouts can be swapped - and you no longer need the UART breakout as there is plenty of RAM?

I2C: SCL = PA9, SDA = PA10
UART: TX = PB10, RX = PB11

[S2000Stefan]

You use generic_map.h for the F103? I have left BOARD_CNC3040 uncommented in my_machine.h, could that be the reason? Change it to a comment again to use generic_map.h: //#define BOARD_CNC3040

o.k. that was the "mistake", but I could have seen it myself. It now works in first tests.

Correct, luckily the EEPROM and the UART breakouts can be swapped - and you no longer need the UART breakout as there is plenty of RAM?

Sounds good to me, I only have to re-solder two piece of wire. And will connect the eeprom to SCL = PA9, SDA = PA10. If everything goes well, I will do some careful tests on the machine with the new controller tomorrow. Yes, I would have enough RAM then. ;-)

[S2000Stefan]

o.k. further tests, basic compiling and activation of the fourth axis works.

// #define ENABLE_SAFETY_DOOR_INPUT_PIN // Default disabled. Uncomment to enable.

After activating the safty door pin, unfortunately no more connection to the controller with ioSender Beta6.

define EEPROM_ENABLE 2 // I2C EEPROM support. Set to 1 for 24LC16(2K), 2 for larger sizes. Requires eeprom plugin.

define EEPROM_IS_FRAM 1 // Uncomment when EEPROM is enabled and chip is FRAM, this to remove write delay.

Activate the EEprom and re-solder to SCL = PA9, SDA = PA10, everything is OK. Unfortunately, the odometer cannot be activated, compiling error:

C:/grblhal_F303/grblHAL-test/grblHAL-test/drivers/STM32F3xx/Debug/../Src/driver.c:1178: undefined reference to `odometer_init' collect2.exe: error: ld returned 1 exit status make: *** [makefile:54: GRBL Driver STM32F303.elf] Error 1 "make -j12 all" terminated with exit code 2. Build might be incomplete.

Unfortunately, it is not possible to run a longer nc programme; after a short time, always of varying length, the nc programme simply stops without an error message.

[terjeio]

Odometer and safety door was easy to fix. Last one was a copy-paste error.

Unfortunately, it is not possible to run a longer nc programme; after a short time, always of varying length, the nc programme simply stops without an error message.

This is potentially more difficult to fix. Currently I have only tested by running my standard program, 9350 line/15 minutes run time with default settings. What is a minimum "short time" you have experienced? Number of lines executed?

ioSender Beta6.

is outdated. Can you try with the last edge version? Beta6 could be the reason behind the hang.

[S2000Stefan]

This is potentially more difficult to fix. Currently I have only tested by running my standard program, 9350 line/15 minutes run time with default settings. What is a minimum "short time" you have experienced? Number of lines executed?

I have also run a few different nc programmes, what can I say, some run through without problems, others do not. Sometimes it stops very early, at block 50, other times it runs through until block 3500. Here is an nc programme where it actually always happens very early. Unfortunately, I have not yet been able to read any correlation. Because there is nothing special in the nc programme. Zweioben#1_Roughing 3.175mm.nc.txt

is outdated. Can you try with the last edge version?

Sorry, my mistake, of course I meant Beta 8.6. I use the new Edge.

[terjeio]

Your program above ran to completion for me and is halway through on a second run. Can you post your settings as it may be related to those?

Can you also post a realtime report after a program stops? Check Verbose in the Console tab to see them.

[S2000Stefan]

Something is special with me again. ;-)

settings.txt

The funny thing is that even if I stop the stopped nc programme with stop, I can continue to work normally in the ioSender. Start nc programme, jogging, change settings...... The controller continues to work normally?

[terjeio]

It's a stepper timer overflow, same problem with STM4xx. I use a 32 bit timer for both and if overflowing it takes quite some time for the next timeout to occur and the process seemingly hangs forever. At the next timeout, which is pretty close to 1 minute, the machine starts to move again... High step rates triggers this overflow.

I have made brute force fix already but that will cause some jitter, I want to avoid that. That means I'll have to dive into the datasheet to find a better solution - give me a bit of time.

[S2000Stefan]

It's a stepper timer overflow, same problem with STM4xx. I use a 32 bit timer for both and if overflowing it takes quite some time for the next timeout to occur and the process seemingly hangs forever. At the next timeout, which is pretty close to 1 minute, the machine starts to move again... High step rates triggers this overflow.

Yes, that's right, after a certain time the programme continues to run, I can confirm that.

[terjeio]

Fix committed. I wrote:

High step rates triggers this overflow.

This was wrong, high acceleration rates triggers this. And only acceleration, not deceleration.

[S2000Stefan]

Fix committed

I did a stress test with the new version on the desktop and it passed with success. I think the controller is now ready to be tested on the machine. Unfortunately, we have a temperature drop here which does not allow me to perform these tests. But I will report back as soon as I have done the tests.

Something else i've had step losses on my z-axis on my last two milling jobs, only on one part of the workpiece. I have not made any changes to the settings (speeds), only changed the firmware and had no step losses before with these settings. My question now is, have you changed anything in the firmware in this direction? I think I have to look for the fault on my hardware side, but it doesn't hurt to ask. ;-)

[terjeio]

Something else i've had step losses on my z-axis on my last two milling jobs, only on one part of the workpiece. I have not made any changes to the settings (speeds), only changed the firmware and had no step losses before with these settings. My question now is, have you changed anything in the firmware in this direction?

One can never be sure - most of the changes lately has been to expand on the settings subsystem. I have done a bit of code refactoring in the central bits of the core (gcode parser, planner, step generator) - most of it just coding style.

I was a bit surprised at the IMO extremely high acceleration settings in the settings file above. You are using those in your machine? High feed rates combined with such acceleration values is likely to lead to lost steps?

[S2000Stefan]

I was a bit surprised at the IMO extremely high acceleration settings in the settings file above. You are using those in your machine? High feed rates combined with such acceleration values is likely to lead to lost steps?

Yes, I have been using these acceleration values on my machine for a long time. In fact, these are only the winter settings in the summer I drive with the same acceleration but then with 4000-4500mm/min maximum rate. I will observe the situation and reduce the acceleration values on the z-axis that had the step losses and approach the maximum again. Or increase the current a little. I'm just surprised that this only happened in one line and didn't happen continuously.

In config.h there is something about "#define ACCELERATION_TICKS_PER_SECOND 100" can I play with this or is this not supported by grblHal? If so, do I have to change "#define SEGMENT_BUFFER_SIZE 10" here too? At least that's how I understand it when I read the text. Thank you for your super support.

[terjeio]

In config.h there is something about "#define ACCELERATION_TICKS_PER_SECOND 100" can I play with this or is this not supported by grblHal?

It is supported. You can override the default values of most settings by adding them to compiler defined symbols via File > Properties > C/C++ > Paths and Symbols > Symbols for the selected project instead of modifying the sorce.

If so, do I have to change "#define SEGMENT_BUFFER_SIZE 10" here too? At least that's how I understand it when I read the text.

I have never played with these settings. Yes there is a relationship between those. grbl does not change step rate smoothly between each step, with the default value it is done every 5 ms.

You may also tune the planner buffer size, BLOCK_BUFFER_SIZE, as this set the limit for max feed rate achievable for short moves. Note that each block buffer entry requires around 40 bytes of RAM. The default for this is 36. The amount of free space is the first value after in |Bf: in the real-time report. You can of monitor this in the console view when a program is running. With the Teensy 4.1 and BLOCK_BUFFER_SIZE = 1400 I have been able to push the max feed rate to over 70000mm/min!

What is a bit strange is that the F103 and F4xx drivers does not sufffer from the same pauses as the F303 does. The driver code is very similar so there is something else at play - perhaps processor speed vs. FPU/no FPU? I will have to dig into this.

[S2000Stefan]

I worked all day today with the new controller (STM32F303) on the real machine without any problems worth mentioning. Version was from 10.01.2021, I just saw that you were very busy ;-) There was also an NC programme with 845000 blocks and a milling time of 80 minutes. I would say that this issue can be closed. :-)

What I noticed for the first time today, when I start the ioSender there is nothing to read in the status bar. If I close it immediately and restart the ioSender again, it appears in the status bar at the bottom: Home cycle required, Home to continue. Shouldn't this be visible at the first start-up? A small cosmetic error? ;-) Also, the display does not disappear immediately after a successful homing.

I also saw that the machine position for all axes are listed in the code, for me only X, Y and Z axis are shown in the fly out tab. Is the display missing? The machine position of the a-axis is not important for me personally, just wanted to mention it.

[gitxmax]

As I suggested this board, glad it seems to be working. I use it now, on my computerized telescope mount over the blue pill. Worth mentioning, the code needs to be compiled with "Optimize Fastest -O3" enabled, to make the full use of the cpu performance,, but I'm not sure, if this is applicable in grblHal case.

[terjeio]

What I noticed for the first time today, when I start the ioSender there is nothing to read in the status bar. If I close it immediately and restart the ioSender again, it appears in the status bar at the bottom: Home cycle required, Home to continue. Shouldn't this be visible at the first start-up? A small cosmetic error? ;-) Also, the display does not disappear immediately after a successful homing.

Yes, both are cosmetic errors that are kind of hard to fix. I think I will need to modify the controller side a bit to get the message display right...

I also saw that the machine position for all axes are listed in the code, for me only X, Y and Z axis are shown in the fly out tab. Is the display missing? The machine position of the a-axis is not important for me personally, just wanted to mention it.

Oops, a misspelling in the code - will be fixed in the next upload.

Worth mentioning, the code needs to be compiled with "Optimize Fastest -O3" enabled, to make the full use of the cpu performance,, but I'm not sure, if this is applicable in grblHal case.

IMO not important unless aiming at maximizing performance. Anyway I'll change release build to -O3 in the next commit. Remember legacy Grbl is running relatively well on a 16MHz 8-bit CPU, a 32bit ARM processor at 72Mhz with a FPU will be at least 10 times faster?