Post Go back to editing

SC589-MINI issues error at programming the flash.

Category: Software
Software Version: CCES 2.9.4

Hi,

About two years ago we have used the SC589-MINI board to run a convolution app; it runs fine.
Now we bought the same board version 2.1 and tried to program the flash with the existing unmodified app using "prog_SAM_flash_ice1000.bat <app-name>", which resulted in
"Error: failed erasing affected sectors" and led1 is on (red).

This error appears at the beginning of flashing after the ldr file is written; no "running dots" are seen.
Next we have rebuild app-name_Core0, app-name_Core1.dxe, app-name_Core2.dxe and tried to program the flash again with the same result.

Finally we tried to run the app with CCES2.9.4 Debug. The program seems to load properly, but does not run.

Which difference(s) between board version 2.1 and the former one 1.5 could cause this issue?

Regards,
Reinier van der Welle
Eminent Organs BV
The Netherlands

Parents
  • There is an alternate to the original bare metal framework available vis github: github.com/.../sam-audio-starter

    and a start of the documentation at:  https://wiki.analog.com/resources/tools-software/sharc-audio-module/advanced-audio-projects

    The flash driver should be the same one as used for the rev 1.5 boards (older versions may have a different flash device).  The rev 2.1 board was created to address component shortages with building the rev 1.5 boards.  The clock generator chip was replaced with discrete oscillators, there is a different USB UART device,  and there is also a different Ethernet PHY.  The sam-audio-starter project runs on both boards and is a good test.

    There is a bootloader included and in the prebuilt folder: https://github.com/analogdevicesinc/sam-audio-starter/tree/1.0.0-Github/bootloader/prebuilt

    the bootloader consists of 2 ldr files - once those 2 loader files are programmed in, then it is possible to reflash the board via a USB cable connected to the OTG port and using the "SAM Flasher" utility. (see instructions on the wiki). 

    This has been tested with a newer version of CCES - it might be worth also installing the latest version of CCES (it will co-exist with your older version).

  • Thanks for your reply. I have made a CCES (2.11.1) project: SAM-Audio-Starter and did the steps from Advanced Audio Projects: Set up pre-requisites, then Set up environment and compile, all without problems. Then Flash the bootloader and application, but execution of "./boot0_hw_rev_1_5_cldp.bat" shows the message "Error: failed erasing affected sectors". An ICE1000 has been used and I have modified the .bat scripts (-emu 2000 to -emu 1000). What could be the cause?

    Thank you for your help.

  • Hi  , ok just to confirm based on your instructions above, you have flashed the bootloader, then reset. Then after this, you have entered the bootloader by pressing PB1 + PB2 and Reset (where LED10 starts blinking (that's a good sign that you have flashed the bootloader correctly - LED10 only blinking means we are in the bootloader). Once you are in the bootloader, you have opened the SAM flasher to attempt to flash the application, but the COM port for USB/OTG does not show up in your list?

    Or you have made it this far, flashed the application (SAM flasher has given you success message), but when you reset, you just get two blinks and then nothing? 

    If this is the case, it is possible there is an unaccounted bug in the software that is preventing your application from starting up (and thus not making it to the shell application). Can you confirm that you are using the latest version of https://github.com/analogdevicesinc/sam-audio-starter which includes a bug fix for the ROMFS (this is the only known bug so far that has prevented the app from running).

    Please let me know if you would like to have a live debug session so we can figure out what is causing your app to not run. 

  • Hi Rebecca,

    I have done the compilation and obtained the file SAM-Audio-Starter.ldr and three more (-ARM.exe, SHARC0.dxe, SHARC0.dxe). Then I have run \Program Files\SAM Flasher\sam-flasher.exe. The COM port did show up, the .ldr file has been flashed, the flasher has given Success!
    Just a question to have it quite clear: the .ldr file is the only one which should be flashed, that is the application?

    During flashing only LED9 is on (green), at the end of flashing LED10 blinks again. Then pressing Reset I get two blinks on LED10. Actually your last remark, which means that the software should have a bug.

    Well, I have downloaded the .zip file on github.com on July, 14, 2023. Un-zipping it, all software (bootloader, build, etc.) is dated December, 15, 2022. And sharc-reusable-components shows version 1.2.0-Github, not 1.0.0-Github. Is that correct?

    Concerning a live debug session, I would prefer to have your comments as text, because my (spoken) English is not that good Slight smile

  • Hi  ok thanks for those details. Yes, it seems you have the right software and something does not look correct. I thought a live debug session would help speed things up as it can be tough to see what is going on without seeing things directly, but as long as you are not in such a big hurry, we can continue chatting by text Slight smile.

    To answer your question - Yes, the .ldr is the file to be flashed by the SAM Flasher. This is the application that combines the ARM, SHARC0 and SHARC1 applications into a single file which is flashed onto the external flash. 

    To start, let's try/check a couple of things.

    1. I should probably clarify, what version of CCES are you using? Though it should not impact, this can change some of the internal driver versions which may have an impact and allow us to try and reproduce on our end (if it is a version we are not using). I see above that you were using 2.9.4. If this is still the case, can you please install the latest version (Should be 2.11.1 I believe: https://www.analog.com/en/design-center/evaluation-hardware-and-software/software/adswt-cces.html ) and ensure your env.sh (in the root of the project) is set to this. Make sure to run source env.sh or ./env.sh and confirm that your path is using this version during the build. If you have the 2.9.4 in your global path, this will be used unless you run the env.sh. 

    2. To confirm, are you using Windows 10? 

    3. To confirm - what are your jumper pin settings. Have you set them back to short pins 1-2? 

    4. Now that you have the software, can you please open up your makefile located in <project_root>/build and under the ARM_CFLAGS , delete or comment out the -DUSB_CDC_STDIO flag. (Note to comment it out you will need to put it on a new line like this and use the hash symbol. 

    Once you do this, please clean the project again and rebuild. (Note that cleaning the project is required). Once you have created a new .ldr file, please flash again with the SAM flasher (it is not required to flash the bootloader again). After you reset to enter the application, please try and connect to the USB/UART header (instead of the USB/OTG) header and try to establish a session in the shell terminal (even if there is only two blinks, we may still see something). If you are able to connect to the shell and do anything like hit enter, please let me know. 

  • Hi Rebecca, to answer your questions:
    1. Yes, I am using CCES2.11.1 as ggeerling suggested on July, 6
    2. Yes, I am using Windows10 Pro 22H2 with the latest August update
    3. Yes, I have never removed the jumper, so I it is on the upper two pins in the yellow box on the above photo, that are pins 1-2 I assume.
    4. I have modified the makefile, -DUSB_CDC_STDIO flag has been removed. But how should I clean the project? I have found the clean command in the makefile.

    I was triggered by your remark "it is not required to flash the bootloader again" and wondered if that flashing had been successful. So I tried that again, but did not succeed. The command "bare-metel-bootloader0.ldr" was flashed and at the end 3 dots and done was shown, but LED1 was on (red) FAULT. Nevertheless I flashed bootloader1 and got 15 dots and done, again with LED1 on. Finally it was possible to flash SAM-Audio-Starter.ldr with known results (green LED 9, two times flashing of LED10). To my humble opinion: the (first) problem is in the bootloader.

  • Hi  , yes, you can clean the project first by running make clean. Then rebuild the project by running make.

    I did do some digging yesterday as well and I do agree. I think right now we are getting stuck in the first stage bootloader. I think the bootloader is expecting to jump to the main application after we reset, but for some reason, that is failing and that is why we are seeing the two blinks and then nothing. So I think it could be possibly a couple of things:

    1. The SAM flasher indicated that the flash was successful (but maybe it wrongly wasn't) -> I want to check the contents of the flash by reading back the LDR and comparing it with the LDR that was built. 

    Or

    2. The configuration of the external flash is in a different state than expected, that may not be compatible with the settings we are trying to use to load the application -> I want to read back the external flash configuration registers and check against our expected settings.

    Or

    3. The SPI pins connected to the external flash are not in the proper muxing state for some reason -> This we would need to probe the hardware.

    One more easy thing we could try before we check out these three options, is to simply try running a debug session in crosscore -> the external flash code will be set up by the EXE/DXEs so this may test theory #2 easily for us. If you are comfortable in CCES, instead of trying to run the application from a SAM flash, can you try loading the DXEs and running the code from the debugger instead and see if you can connect to main that way? (Note, please disable semihosting, under automatic breakpoints). Please let me know if you need more details on how to set up the session. 

  • Hi Rebecca, to be complete regarding your comments from August, 11:  I have run "make clean", created a new .ldr, flashed it using the SAM flasher and obtained the same results, as expected.


    I am reasonably comfortable in CCES (having used it for former EZKIT boards as 21469, 21569, SC589) but did not succeed in using the DXE's in the debugger. Please send me more details how to proceed. Thanks.

  • Hi  , I have added some instructions to our Wiki to help you establish a debug session: https://wiki.analog.com/resources/tools-software/sharc-audio-module/advanced-audio-projects/debug-session?rev=1692098117#debug_session_-_adzs-sc589-mini 

    Please follow these instructions to run the code from the debugger. Once you hit run, please let me know if you are able to access the shell. 

  • Hi  , I was also wondering if you would be willing to share your app-name_Core0, app-name_Core1.dxe, app-name_Core2.dxe (just executables, no source code) so that we can try and reproduce the same issue here? 

  • Hi Rebecca. At the outset I have tried to load the.ldr file used with former versions of the MINI board. Loading was tried using the ICE1000 interface. The app-name was "Convolution_6". ggeerling mentioned the differences between the 1.5 and 2.1 boards. Then I switched to GitBash and so on.
    The present app names are just the same as in your tutorial: SAM-Audio-Starter.ldr, SAM-Audio-Starter-ARM.exe, SAM-Audio-Starter-SHARC0.dxe, SAM-Audio-Starter-SHARC1.dxe.

  • Hi Rebecca, I have followed your tutorial on Setting Up a Debug Session in CCES and have run Debug. The software has been properly loaded (four times message "Load complete"), but the LED on the ICE-1000 does not turn back to green. So no running board; no connection with a COM port, and the 'CP22102N USB to UART Bridge Controller port' is shown when the USB/UART port on the board is used.
    This first test was with the makefile without the -DUSB_CDC_STDIO flag. I have included that flag again, did make clean and an new build and obtained identical results.

    As I have three MINI boards available I have tested the other two with identical results; so no hardware errors, I suppose. A slight difference because the boards are used for the first time, at power up: LED9 and 11 are on, LED10 is blinking, LED7 is on. After loading only LED9 is on; after reset the former situation with LEDS 9, 11, 10 and 7.

Reply
  • Hi Rebecca, I have followed your tutorial on Setting Up a Debug Session in CCES and have run Debug. The software has been properly loaded (four times message "Load complete"), but the LED on the ICE-1000 does not turn back to green. So no running board; no connection with a COM port, and the 'CP22102N USB to UART Bridge Controller port' is shown when the USB/UART port on the board is used.
    This first test was with the makefile without the -DUSB_CDC_STDIO flag. I have included that flag again, did make clean and an new build and obtained identical results.

    As I have three MINI boards available I have tested the other two with identical results; so no hardware errors, I suppose. A slight difference because the boards are used for the first time, at power up: LED9 and 11 are on, LED10 is blinking, LED7 is on. After loading only LED9 is on; after reset the former situation with LEDS 9, 11, 10 and 7.

Children