Unable to run an application without using JLink?
Posted: Wed Jan 13, 2021 1:58 am
Hello, I recently got my hands on a new Quickfeather Development board and was excited to try using it, but am running into a strange problem.
At this point I'm tempted to just buy another board and throw this one away, since the board just doesn't boot up at all without using a debugger. But I thought I would post my question here to see if I can get any advice.
--
After receiving the board, I tried to power it on by connecting it to my laptop with a micro USB cable. However, it doesn't seem to be powering on the way I expect it to. When I try to connect it to my laptop, I see:
- The white LED flashes ON, and then fades to OFF.
- If I press the RESET button or USER button, I don't see anything happen (i.e. the LED stays OFF).
Note that the bootstrap jumpers are not on the board at this point. So I think the board is bricked, and decide to try and recover using the instruction here: https://www.youtube.com/watch?v=Q5GIZUs ... e=youtu.be
I reattach the bootstrap jumpers and connect my JLink to the board.
I follow the above instructions and am able to successfully get the bootloader to talk to TinyFPGA script, and it seems like there is no complaints and I can program the software to the unit. e.g. I tried these commands to program the images to the board, which appears as though there are no complaints (but perhaps I missed something here):
And if I try using the mfgpkg option, it tells me all is fine:
But I don't see any improvement once I remove the jumpers and try to reconnect the board.
In addition, I found that if I connect to the board over JLink and reset & run the board, the demo app does run (i.e. I can control the LEDs and read the state of the user button). But only if I've run the board using JLink.
One other observation is that in JLink, when I perform the reset command, I see some text that appears to suggest my board is currently in reset (i.e. "S_RESET_ST never gets cleared. CPU seems to be kept in reset forever."), which I didn't see in the Youtube video, so perhaps a hardware issue?
--
Any thoughts on something I should try or anything I missed? Would appreciate any advice on this.
At this point I'm tempted to just buy another board and throw this one away, since the board just doesn't boot up at all without using a debugger. But I thought I would post my question here to see if I can get any advice.
--
After receiving the board, I tried to power it on by connecting it to my laptop with a micro USB cable. However, it doesn't seem to be powering on the way I expect it to. When I try to connect it to my laptop, I see:
- The white LED flashes ON, and then fades to OFF.
- If I press the RESET button or USER button, I don't see anything happen (i.e. the LED stays OFF).
Note that the bootstrap jumpers are not on the board at this point. So I think the board is bricked, and decide to try and recover using the instruction here: https://www.youtube.com/watch?v=Q5GIZUs ... e=youtu.be
I reattach the bootstrap jumpers and connect my JLink to the board.
I follow the above instructions and am able to successfully get the bootloader to talk to TinyFPGA script, and it seems like there is no complaints and I can program the software to the unit. e.g. I tried these commands to program the images to the board, which appears as though there are no complaints (but perhaps I missed something here):
Code: Select all
python tinyfpga-programmer-gui.py --bootloader ..\quickfeather-initial-binaries\qf_bootloader.bin --mode m4
python tinyfpga-programmer-gui.py --bootfpga ..\quickfeather-initial-binaries\qf_bootfpga.bin --mode m4
python tinyfpga-programmer-gui.py --m4app ..\quickfeather-initial-binaries\qf_helloworldsw.bin --mode m4
Code: Select all
python tinyfpga-programmer-gui.py --update --mfgpkg ..\quickfeather-initial-binaries --mode m4
CLI mode
ports = ['COM29 (QuickFeather)'] 1
Using port COM29 (QuickFeather)
Skipping programming because CRC matches for ..\quickfeather-initial-binaries/qf_helloworldsw.bin
Skipping programming because CRC matches for ..\quickfeather-initial-binaries/qf_bootloader.bin
Skipping programming because CRC matches for ..\quickfeather-initial-binaries/qf_bootfpga.bin
operating mode : [m4]
setting appfpga inactive
image_info is already set correctly, not writing again
setting m4app active
image_info is already set correctly, not writing again
But I don't see any improvement once I remove the jumpers and try to reconnect the board.
In addition, I found that if I connect to the board over JLink and reset & run the board, the demo app does run (i.e. I can control the LEDs and read the state of the user button). But only if I've run the board using JLink.
One other observation is that in JLink, when I perform the reset command, I see some text that appears to suggest my board is currently in reset (i.e. "S_RESET_ST never gets cleared. CPU seems to be kept in reset forever."), which I didn't see in the Youtube video, so perhaps a hardware issue?
Code: Select all
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Reset: S_RESET_ST never gets cleared. CPU seems to be kept in reset forever.
Reset: Using fallback: Reset pin.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via reset pin
Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
Reset: Reconnecting and manually halting CPU.
Found SW-DP with ID 0x2BA01477
AP map detection skipped. Manually configured AP map found.
AP[0]: AHB-AP (IDR: Not set)
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
Any thoughts on something I should try or anything I missed? Would appreciate any advice on this.