mattdibi / redox-keyboard

Ergonomic split mechanical keyboard
MIT License
1.76k stars 163 forks source link

Cannot flash hex to either side of board (Redox-w v1.0) #101

Closed TheCatster closed 3 years ago

TheCatster commented 3 years ago

Hello! I was happily building my Redox wireless until about early March. Since then, I have been attempting to flash the hex firmware (even going to compile it myself) with no avail. I use Arch Linux on my main workstation and laptop, and have tried installing Ubuntu to better follow the guide on another laptop. I can connect with OpenOCD and telnet to the nrf52s, and "seem" to have a response, but no action. I use an official StLink v2. An example is here:

Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.221053
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for nrf51.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
Info : dropped 'telnet' connection
Info : accepting 'telnet' connection on tcp/4444
Info : dropped 'telnet' connection
Info : accepting 'telnet' connection on tcp/4444
Info : dropped 'telnet' connection

And that's it. I get no response that it's resetting, one that's it's uploading, and nothing seems to be happening. Everything I echo is just accepted and then dropped. What could be the cause of this?

Thank you in advance.

mattdibi commented 3 years ago

Hi, can you show me the commands issued by the other terminal (the echo ones)?

In any case I recently updated the redox firmware repository and it’s now possible to upload the firmware using Docker containers. You can give that a try.

TheCatster commented 3 years ago

Sure, the commands issued were:

I will attempt the docker solution right now, and update you on that!

TheCatster commented 3 years ago

Here is the Docker output for programming the right hand side. Correct me if I'm wrong, but that looks like it succeeded!

============================= PROGRAMMING =============================
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x00000dac msp: 0x20004000
> flash write_image erase /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex
auto erase enabled
Unknown device (HWID 0x000000d1)
using fast async flash loader. This is currently supported
only with ST-Link and CMSIS-DAP. If you have issues, add
"set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0x20004000
wrote 16384 bytes from file /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex in 0.698408s (22.909 KiB/s)
> reset
> Connection closed by foreign host.

============================== FINISHED ===============================

I had never gotten a response when it came to writing, now it says wrote in x time.

mattdibi commented 3 years ago

For documentation purpose, the expected output of any of the

docker exec -it redox-w-firmware_toolchain_1 ./redox-w-firmware/redox-w-keyboard-*/program*.sh

commands is

============================= PROGRAMMING =============================
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset halt
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0xc1000000 pc: 0x00000ba8 msp: 0x20004000
> flash write_image erase /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex
auto erase enabled
Unknown device (HWID 0x000000d1)
using fast async flash loader. This is currently supported
only with ST-Link and CMSIS-DAP. If you have issues, add
"set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000001e msp: 0x20004000
wrote 16384 bytes from file /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex in 0.782274s (20.453 KiB/s)
> reset
> Connection closed by foreign host.

============================== FINISHED ===============================

while on the server side you should see:

openocd_1    | Open On-Chip Debugger 0.9.0 (2018-01-24-01:05)
openocd_1    | Licensed under GNU GPL v2
openocd_1    | For bug reports, read
openocd_1    |  http://openocd.org/doc/doxygen/bugs.html
openocd_1    | WARNING: target/nrf51_stlink.cfg is deprecated, please switch to target/nrf51.cfg
openocd_1    | Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
openocd_1    | Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
openocd_1    | adapter speed: 1000 kHz
openocd_1    | Info : Unable to match requested speed 1000 kHz, using 950 kHz
openocd_1    | Info : Unable to match requested speed 1000 kHz, using 950 kHz
openocd_1    | Info : clock speed 950 kHz
openocd_1    | Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
openocd_1    | Info : using stlink api v2
openocd_1    | Info : Target voltage: 3.274320
openocd_1    | Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
openocd_1    | Info : accepting 'telnet' connection on tcp/4444
openocd_1    | target state: halted
openocd_1    | target halted due to debug-request, current mode: Thread 
openocd_1    | xPSR: 0xc1000000 pc: 0x00000ba8 msp: 0x20004000
openocd_1    | auto erase enabled
openocd_1    | Warn : Unknown device (HWID 0x000000d1)
openocd_1    | Warn : using fast async flash loader. This is currently supported
openocd_1    | Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
openocd_1    | Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
openocd_1    | target state: halted
openocd_1    | target halted due to breakpoint, current mode: Thread 
openocd_1    | xPSR: 0x61000000 pc: 0x2000001e msp: 0x20004000
openocd_1    | wrote 16384 bytes from file /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex in 0.782274s (20.453 KiB/s)
openocd_1    | Info : dropped 'telnet' connection

You can see the OpenOCD server output by issuing:

docker-compose logs openocd

or by launching docker compose in foreground mode (without the -d in the launch command). The important line here is:

openocd_1    | wrote 16384 bytes from file /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-keyboard-basic/custom/armgcc/_build/nrf51822_xxac-keyboard-right.hex in 0.782274s (20.453 KiB/s)

By the look of it you should be good.

TheCatster commented 3 years ago

Yup, that was it for the hands. Just my two cents, but I honestly think the docker method should be the one described in the docs, it's well done. Although this confirms I have an issue with my Arduino or wiring of the receiver, since I still cannot connect to it. I might swap it with a 100% official one to make sure that the issue isn't a knock off. Thank you for your help with this issue!

mattdibi commented 3 years ago

Just my two cents, but I honestly think the docker method should be the one described in the docs

Yeah, I was debating this with myself just today. Thanks for the feedback ;)

Although this confirms I have an issue with my Arduino or wiring of the receiver, since I still cannot connect to it.

If you still have issues open a new issue dedicated to it.

mattdibi commented 3 years ago

@TheCatster BTW just double checking: did you burn the firmware on the receiver’s YJ14015 ?

TheCatster commented 3 years ago

I cannot, that was my major issue right now. I got busy with some other things, but am trying to desolder my Arduino Pro Micro and swap it, I did have an illegitimate one.