Nothing will connect to the USB on the stock board, except the supplied software and the ‘upgrade’ program.
I tried to connect the ‘cube’ via USB before the upgrade and it didn’t see it.
Now that it’s upgraded it has this issue with UART mode.
dfu mode:
I followed the ‘cube’ instruction for connecting to the boot loader, but I got lost here:
I haven’t dealt with this to get into the factory bootloader… have you?
yes. there are Boot0 and Boot1 pins which have to be jumpered in order to upload firmware to the proper memory sections. I generally just use Boot0 for the firmware. Didn’t you have to do this when you blew up your bootloader and had to load manually with the ST-Link pins?
Possible, with the new one, I pressed the button then just uploaded it with st-link hardware… Not sure what happened with the original.
I don’t know for a fact what I did but erase the chip… that was pretty clear.
These bootloaders are done by the factory and are not erasable if I read the documents right…?
I’m not sure if the DFU loader is that low level. I can check by trying to use DFU with the UART/FTDI cable connected to the Bluepill board. Later tonight though.
I tried it with the button, but no different signs of life.
Doug,
Are you done with firmware? Got it all working? You still need to prune it to about 40K, maybe 50K-ish.
I’ve posted earlier that my x2 JL1 purchased at about same time in July, have different flash size, one is 64K and another is 128K. This is long known in Blue Pill world, that some 64K spec parts are actually 128K. This mean that target flash size must be 64K.
I perceive firmware vs. de-scrambling and using factory boot loader as two different efforts.
For Jack:
this is exactly what Doug now is talking about.
I think better code and firmware form Doug is just a matter of time.
De-scrambling is a bit of unknown. It can be super simple, or can be impossible. All depends. It appeared to me as simple but so far I have no idea how to scramble/descramble it.
Factory boot loader, as long as it is not erased or overwritten by STLink - will persist. I have tested it, flash JL3, then whatever else, then back and forth with various bin files - factory boot loader is safe. Feel free to boot into boot loader with button and flash whatever.
STLink however can easily overwrite it. Flashing with standard offset (beginning of the flash) will erase factory boot loader.
Without STLink or other special tool, most people using USB only, will have to live with factory boot loader. So, to use it, we should scramble BIN the same way. At this time the only thing loadable with factory boot loader is JL3 firmware. the good news is that apparently it is not possible to brick it f flashed only through USB (tested on board with 128K, I hope the same is true for 64K board).
Offset for factory firmware is easy to figure out. I’ve learned that flash can only be loaded in 1K chunks. Most boot loaders are 1-4 K. Worst case flash size minus firmware 64-40=24K (24 start addresses), left for boot loader. This is checkable manually, no special tools needed. Most likely will be some offset in full 1K iterations but no more that 8K. (I vaguely recall something that offset is full 1k plus 4 bytes, This info is mostly for Doug, please read about using bootloader+app code and offsets, I believe it is nK+4 or somersetting like that).
Clarification about boot and strapping boot pins:
STLink can flash the chip no matter what boot pins configuration is.
Both boot pins low => start form standard flash offset.
Boot0 high=> start form system memory, this is where factory (ST, not the JL1) boot code is. This is to flash though serial or other interfaces. I have to note that I have 5 year old Blue Pill that can be flashed over serial with Cube Prog as prescribed. JL1 board and latest lot of Blue Pills does not respond to serial connection by Cube. ST stated that they can program system memory to order, but user cannot change anything in system memory. I can speculate that these F103 have custom blanks in the system memory. Maybe somebody get better luck with ST factory boot loader. It is not difficult to jump Boot0 pin on JL1 board. It just appeared that it may or may not be the the option.
Boot1 will make chip to boot from specific offset in RAM. This is very specific use case and probably not for us.
It is not difficult to use command line utility and automate it with script. No need to be programmer, it can be made very simple. However still need 4-pin header and the dongle and driver for dongle installed (which did not install automatically on two ob my windows 10 PCs).
I’ve already posted samples form scrambled and unscrambled BINs. Collective help here can go long way.
Doug, I have two boards, one without boot loader, flashed with my own firmware. The other still have factory boot loader. I can test whatever you have.
Should we get new thread to work on boot loader scrambling?
This one is already unmanageable… you have my vote
it is working from I can tell, ie pwm works on PB0 and when I checked X and Y axis stepper pins they looked to be toggling with move commands. I have not relocated the motor and endstop pins yet. In a post to you I included a link to my repo once I got PB0 remapped and working.
That is what I looked at today and I was not able to shrink it down any from it’s 111K size. If I can not shrink grblHAL down below 64K then it might be a moot point going further with it for this project. Otherwise it would be only of use to anyone with a 128K version of the stm32f103 in the JL1.
There was alot of stuff you posted which I had turned away from when my first order for one of these JL1 machines was refused a few weeks after the order was placed. I did not expect them to show up again. Thanks for reiterating that these are a mixed back of worms and to cover all machines, 64K would be the target memory size to be dealing with. Ouch.
Exactly what I figured too. But I was hoping to have a supported grbl codebase to start from instead of something which has been stale for 2-4+ years. It was a lofty goal it seems.
I would say yes but is the LightBurn forum really the place for these kinds of activities? Maker Forums seems a better place but I really don’t care as I monitor both daily.
if the bootloader-less machine is with 128K that sounds great. I will continue setting up the laserJL1_map.h file using the posts you’d made on where the signals have been mapped.
I’m not there.
GITHub? Your or mine. As a fact this is purely programmatic object, proper thing for GIT.
Agreed that this issue is pretty remote to LightBurn, but so is 90% of everything else on this forum. I guess main draw here is more folks with GRBL system may chose LightBurn vs. alternatives.
Unfortunately the other way around. First one/bootloaderless is 64K. The one that still have factory boot loader is 128K.
I can use Blue Pill and and check with the scope. I did develop/debug my firmware the same way.
FYI, there is additional 64Mb flash chip on SPI bus, firmware can be compiled for that, tho a bit more stuff is involved. I expect it would be in the same address space, but I’m not sure, maybe STM is not aware of this flash. I think originally it was used as cache, that button on JL1 was repeating last work, where STM32 flash was obviously not sufficient for that. Just a thought, So I think there are more ways.
I did edit out significant chunks of the code to slim it. Not in half but I’ve shaved like 10K, down to 40K. Most of GRBLs will compile to about the same size. There must be a lot of irrelevant code in GRBLHAL to swell to over 100K. I think if you start editing out chunks of code - you maybe OK.
I did edit out many cases, mostly related to alternative configurations. Then I did as much as I was able to for unused pins. Was not able to remove everything, but at least some, always checking is anything breaks. Even in my firmware there still more stuff to remove. Maybe, some day.
Some of nice to do would be to upload ESP3D into ESP on board and make some kind of arbitration switch between USB and ESP. But this is later.
grblHAL has support for external EEPROM. The support is for Microchip 24LC16 2K EEPROM and 24AA32 4K - 24AA256 32K EEPROMS.
I will have to see what my JL1 has, 128K or 64K. I don’t think I can shrink grblHAL down anywhere near 64K, let alone 50K. If it’s 64K then I would have to get to where you are with the older 6-axis grbl and accept it’s good enough being old grbl but working.
Just connect STLink and Cube and check. You don’t have to erase anything.
Do you have USB commented out? If you still have USB stack in the code - this is your answer. USB alone can weight tens of K.
Quote from GRBLHAL: " Loosely based on code from robomechs 6-AXIS-USBCNC-GRBL port, updated for STM32CubeIDE and the latest STM HAL drivers where appropriate."
I read it as GRBLHAL is the same 1.1f, it does not use 1.1h. Or you have any indication that GRBLHAL updated to latest GRBL source?
I was not able to find any working source for STM32 that is based on 1.1h.
That is GRBLHAL, higher level code, running as application. In addition, above EEPROMs are slow and memory size is tiny, enough to store settings but not for the application code.
Going lower level, as I have suspected - apparently STM32 has FMC (flexible memory controller) (more here, page 65) that can be configured to use external flash transparently, in continuous internal memory addressing space. I understand that all it need is boot configuration. Then external flash will operate just like internal, no need to change anything in higher level code.
Only need FMC initialization code (or just fuses?) and then configure project for specific flash offset for compilation and flashing. The rest is no different.
Or can be boot loader that starts at standard internal flash offset then jumps to external flash address.
I connected up the ST-Link and it says it’s 128K version. The STM32 is powered from 12V and not USB 5V so DFU mode is a PIA since you need USB connected, 3.3V connected AND Boot0(R19) pulled high(3.3V) then released. Just as well using ST-Link for all comms and power and do the Boot0 pullup thing.
Ah, I was just looking for a repo of grbl which was currently active. I guess there’s a big difference between “active” dev of grbl code and “active” porting efforts. Standard grbl hasn’t been updated in 3 years( 2019 v1.1h).
At least by going the grblHAL route the dev there pointed me to the magic AF mode command to get PWM onto PB0…
This depends what you are doing. I do not see it as PIA at all.
USB powering CH340. I think this is great as it does not drop USB driver when JL1 power is cycled.
When using STLink - board/MCU gets power from STLink interface, this is very convenient.
If we manage to de-scramble/re-scramble firmware then flashing will happened in normal operational setup.
The only minimally inconvenient setup is for erasing factory boot loader and loading straight firmware over serial. But this is the exact scenario we are trying to avoid.
At this time, if you have STLink, why are you trying to connect over serial?
Question: In Cube Prog, bottom right status window, last line “boot loader”, what does it say with your board? Both my boards it is grayed out and I was not able to connect to them over serial, only STLink works.
