Recommended Troubleshooting Steps For Receiver

[TheCatster]

Hello! I've been working on my Redox for a while longer than I wish to admit, and had recently resolved some issues and successfully uploaded firmware to the two halves. However, I am still having issues with the receiver flashing. I had initially thought it was the issue with the Arduino, and swapped to a legitimate Arduino. I still cannot even connect to the receiver. I then resoldered all of the components, and checked voltage and continuity. No luck. To clarify, I cannot connect to it in OpenOCD (or using the Docker uploading).

What are the recommended steps for troubleshooting the receiver? I cannot connect to it, and have had no luck with the aforementioned attempts. Is there something that more commonly gets messed up/goes wrong?

Thank you!

[mattdibi]

Hi,

I had initially thought it was the issue with the Arduino, and swapped to a legitimate Arduino. I still cannot even connect to the receiver. I then resoldered all of the components, and checked voltage and continuity. No luck. To clarify, I cannot connect to it in OpenOCD (or using the Docker uploading).

I think you're mixing some thing up.

The receiver firmware contained in this repository is not for the Arduino. The Arduino hosts the QMK firmware which needs to be uploaded separately using the tools provided by the QMK project.

The receiver firmware is meant for the YJ-14015 microcontroller on the receiver board that then connects to the Arduino. More detailed info here.

Having said that, if you were able to upload the firmware to the two halves, you should be able to upload it to the receiver too. What errors do you see from the OpenOCD side?

[TheCatster]

Yes, sorry, poorly worded. I was mixing it up, which is why those steps ended up doing nothing (I was thinking the MMU somehow communicated through the Pro Micro when using OpenOCD, which isn't the case.) It quite literally does nothing, it sends the basic info it always does and then says something along the lines of "path not found." I'm assuming there is an electrical issue, or I somehow killed the MMU.

[mattdibi]

It quite literally does nothing, it sends the basic info it always does and then says something along the lines of "path not found."

Can you copy & paste the command you issued and the complete output?

[TheCatster]

Sure thing. My exact output is:

 velocity redox-w-firmware on  master
➜ docker exec -it redox-w-firmware_toolchain_1 ./redox-w-firmware/redox-w-receiver-basic/program.sh
=============================== MAKING ================================
rm -rf _build
echo  Makefile
Makefile
mkdir _build
Compiling file: main.c
Compiling file: system_nrf51.c
Compiling file: app_error.c
Compiling file: app_error_weak.c
Compiling file: app_fifo.c
Compiling file: app_util_platform.c
Compiling file: nrf_assert.c
Compiling file: retarget.c
Compiling file: app_uart_fifo.c
Compiling file: nrf_delay.c
Compiling file: nrf_drv_common.c
Compiling file: nrf_drv_uart.c
Assembly file: gcc_startup_nrf51.s
Linking target: nrf51822_xxac-receiver.out
make[1]: Entering directory '/usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-receiver-basic/custom/armgcc'
Preparing: nrf51822_xxac-receiver.bin
Preparing: nrf51822_xxac-receiver.hex

   text    data     bss     dec     hex filename
  16112     144    1584   17840    45b0 _build/nrf51822_xxac-receiver.out

make[1]: Leaving directory '/usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-receiver-basic/custom/armgcc'
45767   /usr/src/nRF5_SDK_11/redox-w-firmware/redox-w-receiver-basic/custom/armgcc/_build/nrf51822_xxac-receiver.hex

============================= PROGRAMMING =============================
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

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

[mattdibi]

telnet: Unable to connect to remote host: Connection refused

There seems to be no OpenOCD instance running. Did you run the docker-compose up command before launching the program script? What is the output in the terminal where you launched docker compose?

[TheCatster]

I did not actually, I was running docker-compose up -d. However, this is showing the same errors I got when I manually ran OpenOCD outside of docker:

 velocity redox-w-firmware on  master took 8s
❯ docker-compose up
Starting redox-w-firmware_openocd_1 ... done
Starting redox-w-firmware_toolchain_1 ... done
Attaching to redox-w-firmware_openocd_1, redox-w-firmware_toolchain_1
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 v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
openocd_1    | Info : using stlink api v2
openocd_1    | Info : Target voltage: 3.210000
openocd_1    | Error: init mode failed (unable to connect to the target)
openocd_1    | in procedure 'init'
openocd_1    | in procedure 'ocd_bouncer'
openocd_1    |
redox-w-firmware_openocd_1 exited with code 1

[mattdibi]

I did not actually

Then it cannot work.

The program script expects to find an OpenOCD instance running somewhere on the machine, it connects to it with telnet and issues the programming commands. Right now the program script can build the firmware but can't find the OpenOCD instance because it quits immediately with Error: init mode failed (unable to connect to the target).

Double check the connection between the STLinkV2 debugger and the YJ14015 of the receiver (be sure to disconnect the recevier board from the Arduino). The expected output of the docker compose command is:

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

Be sure to connect the STLinkV2 to your PC before running the docker command. Likewise the STLinkV2 should already be connected to the YJ14015 before connecting it to your PC.

Once you see the output above you can issue the programming command.

[TheCatster]

No no, I know how to use OpenOCD and Docker. I'm saying I had it open in the background with the -d flag so I did not notice that it did not connect.

Be sure to connect the STLinkV2 to your PC before running the docker command. Likewise the STLinkV2 should already be connected to the YJ14015 before connecting it to your PC.

Yes, always.

(be sure to disconnect the recevier board from the Arduino).

Ah, won't be surprised if that's the answer. I've always tried it attached to the Arduino. I'll desolder now and try that.

[TheCatster]

And sadly, no difference. I still cannot communicate with the receiver.

[TheCatster]

I resoldered all of the components on the PCB. Still not working. Is it possible I have a dead MMU? Is there a way to check?

[mattdibi]

I resoldered all of the components on the PCB. Still not working.

None of the component of the receiver PCB influence how the YJ-14015 behaves during the programming procedure. The module is self-contained and powered by the STLinkV2.

Is it possible I have a dead MMU? Is there a way to check?

Yes, it's possible.

Is there a way to check?

The fact that you cannot establish a connection with it after being able to program both the other halves points to that direction.

[TheCatster]

None of the component of the receiver PCB influence how the YJ-14015 behaves during the programming procedure. The module is self-contained and powered by the STLinkV2.

Huh, I had no idea. Thanks! That does makes sense why that did nothing.

The fact that you cannot establish a connection with it after being able to program both the other halves points to that direction.

Alright, I guess my hail mary will be to attempt resoldering just the MMU again, see if somehow I have poor connections, but then get a new one. Once again, thank you for all your help thus far!

[TheCatster]

Oh boy, I just realised I never closed this issue. Resoldering didn't help, but I swapped out the MMU for a spare and everything worked perfectly. I've been happily using the keyboard for more than half a year. Thank you for your help so long ago!