CoreXY pen plotter

But as usual in this stage, numerous problems emerged. Most obvious is the screen which is upside down.

I've had immense problems with my salvaged microcontrollers, but after some time I got them to work.

I routed the PCB, and I've even made some additional 3d models to aid designing the mechanical part. Now I'll take a break from the routing, and I'll order the boards after refining the firmware and the plotter itself.

Everything is in the github repo.

For now I only laid out the components to see how to optimize the connections. Here are the files : https://github.com/iwasz/zephyr-grbl-plotter/tree/master/pcb/plotter

As I have written yesterday I want to switch from STM32F446RE to STM32405RG because it has more flash and I happen to have a few of them (soldered to variety of prototypes, state unknown). The STM Cube MX reported that the two mcus are pin compatible - at least I understood it that way :

So the only thing to do was to replace the MCU on my nucleo_f446re board, since I do not have any PCB designed yet, and I use the  nucleo for prototyping. Easy! Without even disconnecting the cables (power was cut off of course) I secured other components from heat:

I flushed pins with leaded solder to lower the melting point. Not necessary:

Heated everything up:

And voila! No heart in this patient any more:

Next, using the soldering iron I fixed new (de-soldered) chip in place:

The whole operation took me like 45 minutes, but to my disappointment the board didn't work any more! I'll skip the story of trying 5 consecutive MCUs in a row, suspecting that they are broken. They all have been de-soldered from scrapped (and old) prototypes after all.

Then I compared the pinouts, but this time looked into datasheets. And no, the pinouts are not the same!

TL;DR : pay attention to pins 30-31 and 47 (LQFP 64). In my case I had to remove jumpers SB33 and SB38, and solder C22 and C25.

And at the end:

Finally...

GRBL (running on AVR) uses EEPROM for storing some of its state, but STM32-s doesn't have this type of memory due to its high cost. By the way brand new NXP i MX RT MCUs (at least the fastest ones I think) doesn't even contain the flash memory. I could probably live without the eeprom.c ported because the plotter as it is now seems to draw pretty fine, but I wanted to make my project complete. Default settings are stored in the defaults.h, and although I can change them from the UGS, they are not persisted in the machine.

I tried to get the Zephyr's non volatile storage (NVS) to work, but I quickly ran into problems with my MCU flash layout. STM32F446RE has 512kB. Sectors 0-3 are 16kB, 4 is 64, and lastly sectors 5, 6 and 7 are 128kB long. And now the porblems : 

• First, by default Zephyr defines the storage_partition at address 0x00010000 (counting from the start of the flash) for my MCU, which corresponds to sector 4. And this is problematic because NVS requires at least 2 physical (flash) sectors to operate, and here we have only one. So my idea was to shrink the boot_partition from 64 to 32kB, and then in the sectors 2 and 3 make another storage_partition for the NVS. So far so good.
• Second, the so called "fixed flash partitions" are used by the Zephyr only when a bootloader is used, and I didn't have one.

After compiling the MCUBoot, to my surprise I discovered that the smallest binary I could get is ~36kB in size (only for the bootloader), so there is no way it would fit into sectors 0 and 1. To make things even worse, my main program is ~140kB big (and it's not even finished) while the two partitions for storing it are 128kB. In other words there are strict requirements as to how the flash has to be organized and I can't satisfy them with the current chip.

Alternatives : external EEPROM (takes PCB space, increases complexity), using a SD card (but what if user removes it?), using a MCU with bigger flash (overkill, GRBL stores everything in mere 1kB), using a MCU with smaller flash pages / sectors.

I hit the local distributor website (naive me) to discover that, indeed, the situation hasn't changed, and there's almost no STM32F4xxx available, and only one or two types STM32G4.

So I started to look around my office and found old scrapped boards we did for a client once, and to my delight they all have STM32F405-s with 1M flash. Flash layout is basically the same, and I think I'll finally manage to get it done.

I've replaced (or tested should I say, because in fact I'm about to replace) the motors for different ones. The current model I use are 400 steps JK42HM40-0406 and I was unable to get a smooth and silent operation out of them even though I use the Trinamic's TMC2130 for driving. After come testing I was left with this result table :

And I've decided to go with the 17HS4401. I don't know why my 400 steps ones caused so many problems, the only culprit is the much higher coil resistance which could make current sensing difficult for the drivers. But I'm not sure. I'd love to hear someone's insight on this. And here is the picture for today, the current state of electronics. I plan to design a dedicated board and hide it inside one of those supports you can see on the both sides of the plotter.

This is roughly 15 cm (6 inches) across.

Yay! The very first :

Z-axis is not working though. Yet.