I had today the same problem.
Is there already any official solution from Bambu Lab?
I think there was something wrong with their development when so much user had this issue.
Dude, Iām shocked by your hands-on skills, truly impressive work. However, the firmware and programs for the Cyberbrick are stored in the built-in flash on the chip. Even if you replace the chip, it wonāt resolve the firmware issue. As far as I know, any third-party tool used to flash the firmware will render the core board irrecoverable. The Cyberbrick team should release their official flashing tool this week.
The post from Kido seems to address that. If Iām understanding correctly, the ābaseā programming of the CB ESP32 is a Python interpreter and that boot.py file. Putting a Python interpreter on an ESP32 is pretty easy. But the BBL app wonāt download your python scripts unless it also sees the boot.py file. So including that file will make it work.
1 Like
Hello. Had the same issue yesterday. Today managed to resolve the issue, i will try to explain, sorry my english. Iāve took the faulty receiver with the same symptoms as yours and separated the bottom from the top, separated the one from the transmitter as well and connected the faulty top to the transmitter bottom and flash it with truck firmware and it accepted it. Once done took the top from the transmitter (the one just flashed) and installed it on the truck bottom receiver part and flashed it again with truck firmware and it worked. For the remote, flashed again with its firmware and connected it to the truck with my Windows app. Hope it helps for you as well, let me know. Cheers.
1 Like
Interesting experiment! Good job!
This makes me wonder if, when the Core is plugged into a TX board, the simpler software on the Sender side might make reprogramming it easier. Just a theory that comes to mind from your sequence.
I havenāt received mine yet, but does the Core need to be connected to anything besides USB-C to the computer for it to be programmed?
I have theorized that the Transmit and Receive shields have GPIO 10 hard wired to a level that indicates the type of shield (see rc_main.py code). I think you COULD use just the core board IF you jumper GPIO 10 high or low. High should be a āSenderā, AKA āMasterā.
Given that GPIO10 is adjacent to a GND pin, I suspect that the default is pull up with the Receiver shield pulling it to GND.
The configuration from the application is just a json file that is uploaded via bluetooth, if that is what you mean by programmed. The USB-C is only supplying power.
If someone is able to get a REPL so it can actually be programmed please let me know the secret.
Have you tried connecting it to a computer with USB? The ESP32-C3 controller chip has USB support build in, but itās UART and JTAG, both over USB, so it will normally show up as a UART on the computer (COM?? on Windows, /dev/tty.usb??? on macOS/Linux).
When connecting to that UART I would expect to find a REPL, but as mentioned above I havenāt received mine yet, so canāt confirm yet, but I think it would be pretty odd if they didnāt connect the USB data lines.
I have accessed the Core code using Thonny via the Serial Interface on the USB-C connector. I didnāt go too far with that simply because Iām shelving this work until I get to my Summer home and can really dig into it (about 2 weeks from now). I was, however, able to transfer the python code from the Core processor into the Thonny code window.
I wouldnāt expect much from a simple serial interface to the Core module as the base code doesnāt output anything (other than ESP32 boot data) on that port without some modification. Thonny seemed to get past that to āsomeā degree.
I got it working now, just needed CTRL-C.
They did connect the data lines. Not sure why but it still requires bluetooth to configure.
That worked! I didnāt have any luck with pymakr, but Thonny seems to be working.
And I got the CDC terminal working, CTRL-C was enough.
1 Like
With Thonny connected, Iād try to insert some print statements, especially in the sender code, to verify that correct values are being sent. These could probably be metered so youāre not printing every time through the loop. I āthinkā loop time is second interval, but not certain about that.
Also, try to insert āosdebug(0)ā somewhere in the init code so logs go to the terminal.
Put new batteries in worked for me, seems like they take a lot of power
During setup and testing, the remote should be run on a USB cable with 5V supply IMO. This way the remote stays operating until everything is checked out.