Unable to run an application without using JLink?

Post Reply
rahmant3
Posts: 4
Joined: Sun Jan 10, 2021 11:17 pm

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):

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
And if I try using the mfgpkg option, it tells me all is fine:

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.
anthony-ql
Posts: 49
Joined: Thu Jun 04, 2020 1:26 am

Based on your provided information, it seems that the boot-strap is doing its job. With J1 and J7 removed, when the reset button is pressed and released, S3 will start the SM to access the flash device and check for valid program. If it is OK to proceed, the S3 will load the image from Flash to its internal memory and execute.

If you have the equipment (such as volt meter or oscilloscope) to check for J1 and J7 pin 1, this will confirm if there is HW boot-strap issue. With the Jumpers installed, pin 1 of J1 and J7 should be '1'. When they are removed, the level should be '0'.
rahmant3
Posts: 4
Joined: Sun Jan 10, 2021 11:17 pm

anthony-ql wrote: Wed Jan 13, 2021 3:52 pm Based on your provided information, it seems that the boot-strap is doing its job. With J1 and J7 removed, when the reset button is pressed and released, S3 will start the SM to access the flash device and check for valid program. If it is OK to proceed, the S3 will load the image from Flash to its internal memory and execute.

If you have the equipment (such as volt meter or oscilloscope) to check for J1 and J7 pin 1, this will confirm if there is HW boot-strap issue. With the Jumpers installed, pin 1 of J1 and J7 should be '1'. When they are removed, the level should be '0'.
Hi, thank you very much for the response -- I think it has led me to a useful finding. With a multimeter:

- If I measure pin 1 of J1 and J7 while no jumper is installed, the pin is 0 V.
- If I measure pin 1 of J1 and J7 while the jumper is installed, the pin is 3.3 V.

My issue doesn't appear to be with bootstrap mode. However, I found if I shorted the SYS_RST pin to GND, the board will reset and the application starts running (blue LED starts blinking, and I can interact with the test app over UART). If I try to press the RST button, the board does not reset at all (I'm quite sure the button is getting pressed, but still no success). So my issue appears to be with the RST button... this is fine with me, at least now I can work with the board by shorting the SYS_RST pin to reset it and not have to use a JLink debugger.

Also, one feedback is that if SYS_RST is active low, it would make some sense to name the pin SYS_RST_L or SYS_RSTn to make it clear it is active low when looking at the user guide.
anthony-ql
Posts: 49
Joined: Thu Jun 04, 2020 1:26 am

Good feed back on the naming for SYS_RSTn.
Post Reply