This is $27 - pullback settings.
1 Like
Kung,
-
What is your machine orientation? I comment on the images above two different ways? Which way is it?
-
What happened after $H? Did you laser go to upper right?
-
Use command “?” (just question mark) in terminal. What is reported? ?(after homing with $H)
After press $H the X/Y goto home （upper right）. X/Y Home switch in upper right. But Y after Home it goto lower Y=0. Last fig. the terminal show G0X150Y0 （note: this command not typing by me）. I still not understand this G0X150Y0 command send by firmware or Lightburn？
Now I moved X/Y to object before power up to start the job. So no need to use the Home command
I already setting to monitor your github. When the source code upload to github. I will try to solve this problem.
Sorry too late reply this. Second fig. is correct. Control board in lower side. First fig. just show the Home switch
All,
I’m trying to load my firmware with uploader app into JL1. As already stated - it does not run.
Comparing BINs - it appeared that JL3 firmware (meaning factory boot loader) has some primitive scrambling, but I can’t figure it out. First I thought it is simple addition - but apparently not. If 2D2D2D2D is the key - what is the function?
Anybody sees pattern here?
It is occured to me that this maybe flash offset related. But it is too repetitive and I can clearly see all text messages in compiled GRBL but cannot find any text in that JL3 firmware, that made me think this is scrambled.
Kung,
I’m also not sure if G0X150Y0 coming form LightBurn. To figure it out:
Try to use terminal program, like TerraTerm, and send $H to JL1 board through terminal. See what happened?
You may also try LaserGRBL and try hard home button there.
I also recommend to increase pull-off distance to at least 1.5mm, “$27=1.5”.
and enable soft and hard limits $20=1 and $21=1
All,
Does anybody knows if under some circumstances LightBurn sends laser to the bottom right corner automatically after hard homing?
I’m not aware of anything like this. LightBurn issues homing command and sits back.
Read from TerraTerm
Kung,
Check your “$N”.
I was able to replicate your problem by setting up “$N0=G0X150Y0”.
(also can be “$N1”)
After homing it is executed automatically.
To delete command: “$N0=”
Check again : “$N”
If so - you the only one who knows how it got there.
Kung,
Is everything working as it should?
If so - could you please share your settings? You may export your machine by typing “$$” in terminal and copy and paste whole big response with complete set of GRBL settings.
Would be better as text rather than image.
This will be helpful to others. JL1 currently sold out on Amazon but JL2 is available. I can imagine more people will be doing JL2 GRBL conversion.
$$
$0=6
$1=255
$2=0
$3=3
$4=1
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=1
$21=1
$22=1
$23=0
$24=600.000
$25=3000.000
$26=20
$27=1.500
$30=1000
$31=0
$32=1
$100=80.000
$101=80.000
$102=80.000
$110=3000.000
$111=3000.000
$112=3000.000
$120=400.000
$121=400.000
$122=1000.000
$130=150.000
$131=240.000
$132=1.000
ok
1 Like
it does sound like they are using encryption. My guess is the decryption is getting done in the upload.exe. I’m surprised the uploader would even run on an unencrypted file but as you mentioned, it could be a crude implementation. Have you dumped the firmware from the JL1 and scanned that for strings? Could grab bootloader and firmware and if you find strings late in the address space it’d have to be firmware and show it’s decrypted by uploader.exe.
Brain’s pretty foggy still, do we know they used some version of GRBL or is it some custom firmware which only works with their desktop software application? Could be Marlin or other open source gcode firmware.
I agree, for Windows users having the upload.exe load the firmware would be the easiest as opposed to opening the machine, attaching header pins and ST-Link dongle and flashing raw GRBL to the device.
1 Like
@LsrSal It seems encypting firmware is rather common and is even done on the ST-Link device itself… I found this blog(s) on hacking the ST-Link firmware and uploader and some of it might be handy in figuring out what the JL1 uploader, bootloader and firmware is doing. There’s some ideas on finding encryption keys and a mention of a histogram of the firmware which indicates encryption(which you derived at by looking at the hex dump ).
Lujji might have not made it through covid… he was quite active in 2019, only one post in early 2020 then nothing. 
But his code lives on and in this repo you can find his Java based encrypt/decrypt utility and some others. lujji · GitHub
I’m pretty sure it is, as upper word, if it does not overflow - it is always a sum of original + 0x2D2D. Lower word - is similar bot sometimes does not make sense to me.
I did wiped out my firs board while trying to read factory flash. STM32 has hardware where flipping read protect from ON to OFF automatically wipes off the flash.
FYI, that flash protected area can be read, mostly. This is beyond my capability at this time, but tool is available. Even if read 90% - this is plenty to get better sense of it.
Startup code in BIN is always the same. There is enough data to try to match. You may grab my firmware and JL3 and see by yourself. I do not believe there is an “encryption”. It appeared to me just primitive scrambling and security by obscurity. I approach it as a math puzzle. If not - well, then most folks will have to use STLink if they want full functionality. This is not an investment, but fun.
There are couple unscrambled numerical strings at the end of JL3 firmware. Maybe has something to do with scrambling?
1 Like
Good to know because I was going to try and dump all of the flash on the JL1 and provide you the file for upload and getting your bootloader back. I will not try that now.
Yes, I probably spent an hour looking through GRBLs and GRBL32s all over before I said, 'hey, there has to be a latest GRBL, where and what is it" and that’s when I found GRBL HAL(grblHAL · GitHub) and saw that there were STM32F1xx versions already.
Getting GRBL Hal and building via PlatoformIO(CLI) was just 3 lines:
git clone --recurse-submodules GitHub - grblHAL/STM32F1xx: grblHAL driver for ST STM32F1xx (Redpill, Bluepill)
cd STM32F1xx/
pio run
So you converged on it. Not the GRBL HAL but the one referenced there. This is the starting point for my firmware.
FYI, just as blue pill can have various amount of RAM, - two of JL1 I’ve purchased in July at about same time, I assumed the same lot, but one has 64K and another 128K. So for proper compatibility need to target 64K max. Normally GRBL compiles to ~40K. Plus boot loader, usually less than 4K. Should not be a problem. Unless overloading it with various drivers.
I might be better off if started from GRBLHAL, but in stead I did from …6-axis.
except it’s driving me batty. I can’t get any USB connection once uploaded. I even uploaded a little main.c to blink the LED just so I knew things were running once uploaded. Getting “unable to enumerate USB device”. Recently found “-O s” compile option could be an issue and will dig and try to remove that and see what happens.