Incomplete instructions regarding bootloader

[anomaly256]

If the use-case involves loading the appfpga binary (with or without the m4app binary) which is now supported in this programmer application, then the bootloader needs to be updated on the QuickFeather first The latest version of the bootloader can be built in the qorc-sdk (qf_apps/qf_bootloader or qf_apps/qf_bootloader_uart).

I followed this and flashed qf_bootloader_uart thinking the '_uart' meant you would be able to access the bootloader for further flashing on the feather rx/tx pins, or possible the usb serial uart on the board - apparently not, this made the board entirely unusable apart from SWD. I didn't have an SWD adapter at the time so I ordered a second board while waiting for one to arrive. This time I flashed qf_bootloader thinking it must be the right one given the past experience - apparently this assumption was also wrong and now this second board is also unusable without an swd cable, however it at least makes a usb serial device - but hangs when trying to talk to it and the green led doesn't blink as with the original bootloader.

Why are these intructions here and what's missing from them?

Thanks

[coolbreeze413]

@anomaly256 Sorry to hear that you are having a bad experience updating the bootloader.

The clear steps are present as part of the qorc-sdk setup here: https://qorc-sdk.readthedocs.io/en/latest/qorc-setup/qorc-setup.html#bootloader-update

If you have flashed the qf_bootloader_uart, then you should be able to use the tx,rx pins on the Quickfeather board to flash from the next reset onwards, by connecting any 3.3v common USB-UART adapter to those pins, and while using this, the tty port will show up as a /dev/ttyUSBx - and this is what you will need to use as the port parameter to the programmer.

To use the USB port on the Quickfeather board, you are right to flash the qf_bootloader which will present a /dev/ttyACMx port which you can use to flash with the programmer, same as with a new board.

It is strange that you are not seeing the green LED flash. To clarify, once you plug in the board, and press reset and you do see the blue led start flashing? Once you press the usr button during this time, you do see the /dev/ttyACMx port show up in lsusb output, but you dont see the green led flashing?

Could you also let us know what OS and version you are trying it on? Did you see the flashing of the new bootloader go through successfully? If the flashing does not complete, this may cause the behavior you are seeing.

[anomaly256]

@anomaly256 Sorry to hear that you are having a bad experience updating the bootloader.

The clear steps are present as part of the qorc-sdk setup here: https://qorc-sdk.readthedocs.io/en/latest/qorc-setup/qorc-setup.html#bootloader-update

I did follow that, the building and flashing of the bootloader succeeded, and it does boot, it's just uncontactable on the uart or usb

If you have flashed the qf_bootloader_uart, then you should be able to use the tx,rx pins on the Quickfeather board to flash from the next reset onwards, by connecting any 3.3v common USB-UART adapter to those pins, and while using this, the tty port will show up as a /dev/ttyUSBx - and this is what you will need to use as the port parameter to the programmer.

I've tried this and it doesn't work, the flash tool never recognizes it.

To use the USB port on the Quickfeather board, you are right to flash the qf_bootloader which will present a /dev/ttyACMx port which you can use to flash with the programmer, same as with a new board.

It is strange that you are not seeing the green LED flash. To clarify, once you plug in the board, and press reset and you do see the blue led start flashing? Once you press the usr button during this time, you do see the /dev/ttyACMx port show up in lsusb output, but you dont see the green led flashing?

I see the blue LED flashing. If I do nothing it then goes solid red after a few seconds. If I press the user button it changes to green but solid, not with the periodic blink. ttyACM0 shows up but I am unable to actually talk to it using either screen or the flash tool

Could you also let us know what OS and version you are trying it on? Did you see the flashing of the new bootloader go through successfully? If the flashing does not complete, this may cause the behavior you are seeing.

In both cases it succeeded flashing successfully and going by the LEDs it is running on a reset, but I am just unable to talk to it using usb or the uart pins where I was able to with the factory version.

edit: Using KDE Neon (ubuntu 20.04 based)

[anomaly256]

Btw, while waiting for a j-link edu to arrive I'll see if I can get them recovered using an stlink v2 and openocd and see if the issue persists after flashing 'qf-initial-bins'. Maybe something just went wrong during compiling

[coolbreeze413]

Let's take the debug into 2 parts: 1 for the board where you have the qf_bootloader_uart flashed, and one for where you have the qf_bootloader flashed.

1. qf_bootloader_uart

I assume that, when you reset this board, you see the blue LED flashing, and when pressing the usr button, you see the green LED flashing as well.

Once the green LED is flashing, you could execute something like this (to read from flash the current state): qfprog --port /dev/ttyUSB0 --crc --mode

Once the green LED is flashing, you execute something similar to (to test flashing): qfprog --port /ttyUSB0 --m4app output/bin/qf_helloworldsw.bin --mode m4

What is the output you see from qfprog here? Does it just get stuck?

2. qf_bootloader

With this one, there are also debug prints that appear over the QuickFeather UART Tx pins, so keep the USB-UART connected and open up a serial terminal on the /dev/ttyUSB0 to see the debug prints. Could you post the output you see on the serial terminal from when you reset the board (blue LED flash starts) and then on pressing the usr button (green LED goes to solid, but no blink). If you don't press usr button, and then LED goes to red it indicates that the bootloader encountered an error in loading either m4app/appfpga from flash, depending on the current mode set.

[anomaly256]

1. qf_bootloader_uart

I assume that, when you reset this board, you see the blue LED flashing, and when pressing the usr button, you see the green LED flashing as well.

No sorry, the green LED isn't flashing on this one either, just solid like qf_bootloader

[anomaly256]

2. qf_bootloader

With this one, there are also debug prints that appear over the QuickFeather UART Tx pins, so keep the USB-UART connected and open up a serial terminal on the /dev/ttyUSB0 to see the debug prints. Could you post the output you see on the serial terminal from when you reset the board (blue LED flash starts) and then on pressing the usr button (green LED goes to solid, but no blink). If you don't press usr button, and then LED goes to red it indicates that the bootloader encountered an error in loading either m4app/appfpga from flash, depending on the current mode set.

##########################
Quicklogic QuickFeather Bootloader
SW Version: qorc-sdk/qf-apps/qf_bootloader(v2.1) (GCC)
Feb 22 2021 20:36:40
##########################

User button pressed: switch to download mode
****ASSERT****
assert: /home/anomaly/src/quickfeather/qorc-sdk/qf_apps/qf_bootloader/GCC_Project/../../../freertos_gateware/src/eoss3_hal_fpga_usbserial.c
line: 65
SOFT FAULT

[coolbreeze413]

Ah, that's strange, it looks like the USBSERIAL IP is not loaded into the FPGA, due to which the failure is seen, when the bootloader tries to check the FPGA IP integrity.

This should not be the case, as it should already be there in the factory programmed QuickFeather board.

This is also probably causing the UART bootloader to stop, as internally it does load the same USBSERIAL IP on FPGA for debug prints.

I am guessing that the bootfpga section in the flash (where the USBSERIAL IP FPGA binary resides) somehow got corrupt while updating the bootloader - though we have never seen this happen in our tests before.

Would it be right to assume that you only updated the bootloader and not the bootfpga section while updating the bootloader, using a command similar to this: qfprog --port <PORTNAME> --bootloader output/bin/qf_bootloader.bin --mode m4

I think that the only way to recover this would be with the SWD, as the bootloader cannot really work without the USBSERIAL IP Core. I will take this as an input to fix the UART bootloader to remove possible dependency on the FPGA part.

I will check on the openocd method, and update with the notes I had while using it, though officially it is not yet published due to the fact that it has not been tested enough, only the J-Link has been thoroughly tested.

[anomaly256]

Would it be right to assume that you only updated the bootloader and not the bootfpga section while updating the bootloader, using a command similar to this: qfprog --port <PORTNAME> --bootloader output/bin/qf_bootloader.bin --mode m4

Correct, just double checked my bash history and I was only passing --bootloader not --bootfpga

I think that the only way to recover this would be with the SWD, as the bootloader cannot really work without the USBSERIAL IP Core. I will take this as an input to fix the UART bootloader to remove possible dependency on the FPGA part.

I will check on the openocd method, and update with the notes I had while using it, though officially it is not yet published due to the fact that it has not been tested enough, only the J-Link has been thoroughly tested.

Cool, thanks. I did find a couple issues in the upstreamed quickfeather openocd board and target configs btw, but I haven't filed bugs against them yet - do QuickLogic maintain these or were they submitted by someone else?

board/quicklogic_quickfeather.cfg I had to change transport swd to transport hla_swd, reset_config srst_only to reset_config none separate but these may be a side effect of my stlink v2 clone

target/eos_s3.cfg line 29 the var ref _CPUTAPID is missing a $: swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf -expected-id _CPUTAPID to swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf -expected-id $_CPUTAPID

[timsaxe]

A point: the programmer has a crc operation –crc that prints the crc for the various blocks. I don’t think that will help solve the problem, but it could be used to confirm if the fpga section got smashed somehow.

From: Krishna Kumar notifications@github.com Sent: Wednesday, February 24, 2021 10:21 PM To: QuickLogic-Corp/TinyFPGA-Programmer-Application TinyFPGA-Programmer-Application@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [QuickLogic-Corp/TinyFPGA-Programmer-Application] Incomplete instructions regarding bootloader (#13)

Ah, that's strange, it looks like the USBSERIAL IP is not loaded into the FPGA, due to which the failure is seen, when the bootloader tries to check the FPGA IP integrity.

This should not be the case, as it should already be there in the factory programmed QuickFeather board.

This is also probably causing the UART bootloader to stop, as internally it does load the same USBSERIAL IP on FPGA for debug prints.

I am guessing that the bootfpga section in the flash (where the USBSERIAL IP FPGA binary resides) somehow got corrupt while updating the bootloader - though we have never seen this happen in our tests before.

Would it be right to assume that you only updated the bootloader and not the bootfpga section while updating the bootloader, using a command similar to this: qfprog --port --bootloader output/bin/qf_bootloader.bin --mode m4

I think that the only way to recover this would be with the SWD, as the bootloader cannot really work without the USBSERIAL IP Core. I will take this as an input to fix the UART bootloader to remove possible dependency on the FPGA part.

I will check on the openocd method, and update with the notes I had while using it, though officially it is not yet published due to the fact that it has not been tested enough, only the J-Link has been thoroughly tested.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/QuickLogic-Corp/TinyFPGA-Programmer-Application/issues/13#issuecomment-785647178, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AO4FHENCXYBZPYB2EBSQ7BDTAXT6DANCNFSM4YFZQCEQ.

[coolbreeze413]

Thanks for the openocd inputs, the cfg files for the eos-s3 target and quickfeather board were contributed by AntMicro, as a partner of QuickLogic, and it can be considered to be maintained jointly. If you do find problems, please do file bugs, it will only help everyone in the community.

The transport and reset config should ideally not need to be changed, but as you mentioned, this might be due to using stlink, I would need to double-check that.

@timsaxe Yes, I suggested the same, however, because of the check against the bootfpga, the bootloader enters into error mode, and does not accept any more commands from the host, so we cannot run these commands in this situation. For the qf_bootloader, it makes sense, as the only way of communication with the host PC is via the bootfpga, however for thw qf_bootloader_uart, we can enable the bootloader to keep running and accepting commands over the UART even if the USBSERIAL FPGA IP failed to load from flash.

[anomaly256]

(emailed openocd-devel regarding the eos s3 target config btw)

[coolbreeze413]

@kgugala Could you help to check @anomaly256 inputs on the openocd configuration for the eos-s3?

[anomaly256]

Managed to recover the board with OpenOCD and qf_loadflash.bin. Happy to do some further tests and diagnostics to find out what failed where over the next few days

[coolbreeze413]

Great to hear that! Yes, if you could just repeat the bootloader flash to check if you are indeed getting this issue, we would be happy to look into it. Thanks!

[anomaly256]

I tested flashing quick-feather-dev-board/binaries/qf_bootloader.bin, checking crc before and after, then resetting. The crcs were unchanged, and the device booted normally after. I then flashed qorc-sdk/qf_apps/qf_bootloader/GCC_Project/output/bin/qf_bootloader.bin and did the same. The bootloader section's crc changed as expected and bootfpga's did not - however on reset the device failed to bring up the usb serial interface as before and the green light was solid. before flashing:

bootloader: b'70fdca7e149e0000'
boot fpga : b'304ca76db8280100'
M4 app    : b'9c096cb71cbf0100'
app fpga  : b'ffffffffffffffff'
operating mode : [m4]

after:

bootloader: b'3debca89709b0000'
boot fpga : b'304ca76db8280100'
M4 app    : b'9c096cb71cbf0100'
app fpga  : b'ffffffffffffffff'
operating mode : [m4]

Ofc at this stage I am unable to run the flashtool's crc check, but I'll step through the bootloader execution and see where it's triping over when I get a spare few minutes

edit: just realised I can do the crc check via qf_loadflash, it looks like the bootfpga section remains unchanged:

bootloader: b'3debca89709b0000'
boot fpga : b'304ca76db8280100'
M4 app    : b'9c096cb71cbf0100'
app fpga  : b'ffffffffffffffff'
operating mode : [m4]

[coolbreeze413]

@anomaly256 Thanks a lot for the update.

I will try the same thing with the latest qorc-sdk and narrow down the problem, it looks like its in the bootloader.

Could you confirm how you setup the qorc-sdk dependencies (toolchain etc.) - Did you use the envsetup.sh or manually setup the gcc/SymbiFlow/programmer?

What is the size of the qf_bootloader.bin you see after you have built the bin?

[anomaly256]

I followed https://github.com/QuickLogic-Corp/Getting_started which lead to https://github.com/QuickLogic-Corp/qorc-sdk#toolchain which lead to https://github.com/QuickLogic-Corp/quicklogic-fpga-toolchain#1-run-an-installer-and-run-an-example , I didn't see envsetup.sh mentioned anywhere yet.

my qf_bootloader.bin is 39792b - would it help if I attached it? or should I just scrap this env and start again with envsetup.sh?

[coolbreeze413]

It should not make a difference, the envsetup.sh conveniently wraps the installation, and takes care of setting the env whenever you open a new terminal, so that you don't need to add anything permanently to the global env(in case you have other platforms/toolchains installed).

That is covered here: https://qorc-sdk.readthedocs.io/en/latest/qorc-setup/qorc-setup.html

Due to this being a relatively new approach for us, the github links are yet to be updated with this info, we plan to update it to be consistent soon.

The bin file size looks ok, I will do the debug today and update, if needed then, we can look at the bin file you got after compilation.

[anomaly256]

No worries, thanks. I'll try setting up a clean env with envsetup anyway in case I missed something.

[anomaly256]

Well, with a new env the resulting qf_bootloader.bin is 68 bytes larger and works properly after flashing - I must have messed something up in the env initially, or chose too new an arm gcc toolchain (10.2.1) maybe

[coolbreeze413]

That's great news!

We have seen issues when switching to a newer compiler, we had issues when moving from 7.x to 9.x. The 10.x version is most likely the problem here, if you build the older setup with the 9.x, I believe that will work too.

Currently all the testing is done with the 9-2020-q2-update version only and we don't yet have plans to move to the 10.x as of now.

BTW, feedback on the envsetup.sh method would help us. Does that look like a good way to setup the env, and did you have any problems (network issues etc) while running the script?

[anomaly256]

That's ok, I have no great need for 10.x. Thanks for pointing me in various helpful directions.

I didn't have any issues running envsetup.sh and I like the approach. And.. it results in a well-known combination of component versions so someone doesn't download the wrong arm toolchain thinking it shouldn't matter too much to just grab the latest.

Closing the issue, thanks again

[coolbreeze413]

@anomaly256 I just got a STLink V2 clone to test it out with the QuickFeather. I could connect and run the qf_loadflash with openocd, with the bug-fix you reported on line 29 of the eos_s3.cfg needed, but did not need to change the transport or reset_config but openocd took on the values you mentioned automatically. Used xPack OpenOCD v0.10.0-15 to test.

Out of curiosity, how did you manage to connect it with the QuickFeather SWD lines, did you use one of the 2.54 to 1.27 5x2 converter boards?

[anomaly256]

I used one of these ADA2743. I tried again with the original reset_config and it works, I guess I had RST loose before. The transport line change is still needed though on my end. I can try later with xPack openocd if you like