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
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.
@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?
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.
Maybe this is for the best? By default Blue Pill GRBL source uses serial over USB. JL1 does not use USB, but plain serial. USB library have to be removed to change default serial from USB to straight UART.
It is very possible that with USB enabled there is no room in 64K for GRBL. Though with 128K I run Blue Pill GRBL over USB without any issue.
JL1 has CH340 for USB that interfaced to UART port on STM32.
What are you using to compile and upload? Atollic? Arduino? Cube?
Maybe you got first bump on this road of HAL stuff. It is not enough to compile code to call USB (then Timer for PWM) function. they have to be enabled and configured, usually with HALCoGen (i.e. Cube MX), or chip definition in Arduino, where you specifically have to select USB functions, like USB serial or HID or DFU or custom USB ID.
What puzzles me is that misconfigured HAL stuff fails silently. I think. Maybe I’m checking wrong places?
Hey, I’m just trying to get to a starting point and planned on customizing later.
Regarding the project size, yes it seems to be building to 127K and when I specify the 103c8 for the board it can’t link because there’s no room.
none of the above, PlatformIO
But when I started searching for issues with USB I see a post from 2021 about lack of PlatformIO support so it is rather new. I don’t know what Atollic or Cube are but I’ve heard of Arduino. 
I’m not sure how PlatforIO handles HAL. Arduino has limited predefined options. Most other environments still require to use CubeMX to generate HAL init. MX then can import initial code to selected bunch of environments. If not Cube MX then you have to have some template with USB enabled in HAL.
I edit HAL for PWM by hand. I would not try to manually edit USB portion of the HAL.
Can you open and compile GRBLHAL in PlatfromIO?
getting Atollic
OMG, they give me a download link and no instructions… get a file, en.TrueSTUDIO_V9.3_lin.gz and decompress and it’s not executable and looks like a script. But what is this at the start of the file:
Atollic_TrueSTUDIO_for_STM32_9.3.0_installer/0000755000000000000000000000000013430475231017436 5ustar rootrootAtollic_TrueSTUDIO_for_STM32_9.3.0_installer/install.sh0000755000000000000000000001660513430475231021453 0ustar rootroot#!/bin/bash
################################################################################
# Copyright (c) 2018 STMicroelectronics Software AB.
# All rights reserved. This program and the accompanying materials
# is the property of STMicroelectronics Software AB and must not be
# reproduced, disclosed to any third party, or used in any
# unauthorized manner without written consent.
################################################################################
set -eu
Getting CubeIDE instead.
I got Windows True Studio installer - no problem. This is what I’m using right now.
ST themselves apparently (as per release notes) expecting us not to use not the Cube Prog anymore but Atollic instead. The talk is that Cube Prog free is more limited, Atollic free apparently better. I did not compile anything in the Cube. My JL1 compiled in Atollic on Windows. No issues and I did not encounter any limitations.
If you are installing in Linux - I would expect it to be the script. You do not expect it to be in Linux repository, so script is logical. But I have little Linux experience, mostly servers stuff, never desktop.
But then there is a problem to link HAL from Cube MX. Creating brand new HAL and opening it in Atollic - no problem. To get Atollic project and redo HAL in MX and then back annotate - this is where it breaks for me.
Fun stuff!
sorry but that will not work on Linux.
great, so I’ll see what they have for uninstall. Ya, that botched downloaded file is a script but they boogered it up with some snot at the front if it. 800MB file doesn’t fit in my editor very well and gawd it’s been decades since I used a line editor. I can probably use sed to strip the first few lines out of it but those yahoo’s need to act like software developers. Who in the hell QC’d that thing!
Burned out on this today after over 6 hours.
Wine? (I had limited success with that). But it is not right to translate when native app is available. Just thinking aloud.
Good luck!
I think you have it mixed up regarding Cube MX being dropped and Studio being recommended. I looked and ST Cube MX is pushed all over the place and where I found Studio listed it as a “not recommended for new projects” flag on it. According to the docs on how to compile grblHAL they recommend Eclipse based setup and give instructions on using STM32CubeIDE.
I don’t know if True Studio is also Eclipse based but if it is, that platform has been running on Linux and other OSs for a couple of decades.
Doug,
I will not argue about these aspects with professional firmware developer. You are quite possible right. I’m firmware hobbyist. I did what first worked for me. I do not make living with it. I will not chase minute conveniences or performance aspects of one tool chain vs the other. At the end of the day my environment is setup, functional, and I was able to produce working code.
I can imagine if professional see my code they may cringe. Whatever.
So I’m more curious about your way.
If you use Cube all the way end to end, I guess you will have better chance to do it right with HAL and edit hardware timer in MX and then back annotate to Cube IDE to do it proper way.
There is more than one way to skin the cat.
Looks like you started to find your own way. I will support you as much as I can. Hope to learn form you.