I bite my tongue and go to try to load it again. If it work and looks like nobody really struggle without homing cycle or cross pointer - why would I need to rewrite this firmware? I may still work on it just to learn about this darn TIM1 hardware in STM32.
I already got my DLC32 setup and running. Today I got set of 2209 drivers. Oh it is so silent! No buzz at all!
Good reason!
They are duplicates of @JVL post 162.
Lightburn connects, the machine just isn’t responding as expected.
Did the machine come pre-assembled? If X and Y are swapped this is either a firmware issue where pins are swapped or possibly stuck in homing mode like @LsrSal is indicating.
You may want to review the cables in case it was assembled incorrectly.
Can you run these commands in Console and return results?
$I
$$
$#
?
Can’t now… tried to reload the firmware ROM.bin and now it won’t talk… guess I’m too tired to be doing this… I’m shutting down till tomorrow…
Catch y’all tomorrow… thanks
This thread has much detail about the NWT I’m using… paint is Krylon ColorMaxx flat-white.
I’ve used lasers from 2.3W up to Neje dual-diode laser (10W-12W)… they all will do ceramic tiles but each has its own best settings. I do a NWT grid tile for each one. Here are 5 different lasers test tiles… all using the same Krylon ColorMaxx flat-whte paint
Test tiles, different lasers… 2.3W, 3W, ~4.5W, ~5W and ~10W (left to right, top to bottom)
Find the “blackest black” and use that speed and power for best results with that laser and paint.
Just tried again to load it using Cube: not running for me. It did report that upload completed and verified successfully, but core is locked up, meaning not able to execute the code. I’ve tried various option bits. Also should be “Run after programming”.
This is consistent with my previous experience.
I guess I have to continue…
I know zero about the stm32, I was just trying to save the board. I didn’t try to set anything and I read the start address (I guess) when I loaded the binary.
Have a hard time with the ‘locked core’, mine would talk over the serial port, how could that happen if the core was ‘locked’. That means unless you tell it to ‘run after programming’ it wouldn’t work at all? That seems illogical…who would want to load something and not execute it at some point?
My assumption is, I’m not following you…
Since my last load of the ROM.bin, I get no communications either… starting to wonder if I got the right binary… bummer it won’t talk anymore.
This thread is so large, I can’t find anything in it and I think I’ll try and start a new one on firmware upgrading these and let this one die…
Hi Jack, I also recommend a thread on building GRBL and uploading via STM32 ST-Link interface.
So one thread on using their update.exe to load a guessed at ROM.bin and another on compiling and loading GRBL specifically setup for this stm32 board.
Might also be better to have them on the http://forum.makerforums.info site. $0.02
Doug/All,
The “guessed at ROM.bin” does indeed seem to be a valid GRBL 1.1f image… a couple of us are using it without issue now.
That “update.exe” is a very minimalist program… no status/messages and only a labeled button and progresss bar. It does what it’s supposed to do but I think the last screen update of the progress bar is so fast that folks are thinking it’s crashing at 80% completion… when it’s not. It completes and returns to the exact look it had at the beginning so you have no clue what it did. I proceeded as if it did complete (it had functioned “normally” to 80%… so why crash now?) and was rewarded with a functioning GRBL machine.
Since the discussion has drifted beyond the OT, I agree it should probably have its own thread.
– David
Safety ‘disk’ in lieu of the glasses… help to focus…
That is described in my JL1 manual as
“Anti-light glasses + protective lenses to block laser brightness and protect eyes.”
Hmmm, maybe I should have read a little further.
I applied the ‘run’ option and got the ‘core is locked’ but when I try to follow the steps I find on Google, they interface is different from mine to theirs. I’m sure it’s an update and the same information is there, but as far as I can tell, it’s open from the status…
Don’t even really know what ‘core is locked’ means…
It’s explained like this on stack exchange
Unfortunately mine looks like this, making it more difficult to follow… I’m sure the same information is there, but not sure how to translate.
It also states in the ‘cube’ manual that only the binary files need to have a start address specified in the programmer. Notice that the ROM.bin when loaded leaves the load address empty.
With the WRP0… they are all read as being ‘checked’ indicating ‘write protection not active on this sector.’
Did you manage to unlock the core…? Haven’t found a description of a ‘locked core’ yet.
I thought so, but when I loaded the software, then went to the programming tab and loaded the ROM.bin, it did not fill in the ‘start address’. I don’t know how it got in there before.
I also don’t know how or why the core is still locked.
It likely defaults to 0x08000000 based on the MCU but it will retain whatever value you last had there.
I suggest you try reinstalling @LsrSal’s binary file to see if you can at least get serial connectivity back.
Do you have any clue about the “Warning: The core is locked up” do I need to unlock this?
This is from post 189
Did you change any of the options in OB?
What happens if you disable “Run after programming” and just power cycle the machine after programming?
Post 189 I unchecked RDP and ‘apply’
Any clue about the ‘locked core’?
