Post Go back to editing

Uploading code without boot jumper on SHARC Audio Module does not reboot

Category: Software
Product Number: SHARC Audio Module

When I send the code of the VirtualAnalog synth in RELEASE mode through the debugger it works perfectly, the Debugger goes pink, the yellow LEDs 10, 11 and 12 blink, and sound comes out and interacts with MIDI perfectly. I upload the code without the BOOT jumper and then I disconnect  the DEBUG connector, turn it off, put the jumper on the pins 1-2 (closest to the ethernet connector). When I turn it on it doesn't reboot. I have to upload the code again through the debugger for it to work. What is going on?

[edited by: lallison at 2:15 PM (GMT -4) on 11 May 2022]
  • i have the same question... ever figure it out?

  • I never saw this follow up question for whatever reason back in 2020. What are you doing to create the bootable ldr file? Do you see the red fault light come on? Also, be sure that you have no file IO happening on the ARM core. Have you looked at the UART logging to see if it indicates what went wrong?



  • i am using the tutorials found in the crosscore wiki that were referenced in SAM documentation:

    i am able to run/demo my code using the debugger but when I try the boot load stuff, I get nothing.  i am kind of a newb to this stuff but from what i can tell:

    1. after some project configuration for each core, create .ldr file by building the project.  it appears in core2.
      • note, i have toggled 'both cores' to false in src/common/audio_system_config.h for each core project to reduce the complexity of my app
      • if i use this setting, should i be treating my core1 as the loader project (step 3&4 below)?
        #define USE_BOTH_CORES_TO_PROCESS_AUDIO               FALSE
    2. include the v10 initcode in the Initialization section of CrossCore SHARC Loader for core2 project properties 
      • ...\CrossCore Embedded Studio 2.10.0\SHARC\ldr\ezkitSC589_initcode_core0_v10
    3. core0 and core1 are set to 'Executable' Build Artifact, extension dxe whereas core2 is set to loader file in Build Artifact, extension ldr. 
    4. core2 project properties Executable Files section of CrossCore SHARC Loader, each core has its exe selected per that procedure in the links above...
    5. each project core properties is set to Debug for configuration in Build Settings, should it be set to release?
    6. then i am using the clpd to load my files into the SPI flash with the following command: 
      C:\Analog Devices\CrossCore Embedded Studio 2.10.0>cldp -proc ADSP-SC589 -emu ICE-1000 -core 1 -driver "C:\Analog Devices\SAM_BareMetal_SDK-Rel2.1.2\extras\flash-programmer\Supporting_Files\sam_dpia_Core1.dxe" -core 1 -cmd prog -erase affected -file "C:\Users\mswanson\cces\2.10.0\gungaGaLooper\gungaGaLooper_core2\Debug\gungaGaLooper_core2.ldr"
    7. After the clpd completes, it says Done... so no errors seem to appear.  
    8. Now I connect the jumper across JP1, connecting the two pins that are closer to the USB port (opposite of ethernet prt).  I am really unsure which side needs to be connected for to boot an app.  I've tried both.  
    9. Then I remove power & USB from the SAM board and ICE-1000 emulator
    10. Power SAM board back up (without USB) and nothing happens

    Hope that helps with understanding my setup.  Let me know if anything else looks funny...



  • Hi Mike,

    For anything SHARC Audio Module related you should be able to find most information you need at

    Specifically for booting, the easiest thing to do is follow:

    We added that page and the accompanying batch files so that users new to CCES would not have to worry as much about the complexity of figuring things out in CCES.

    Using Debug configuration is fine but just keep everything set to build executable artifacts and then following the flashing page above. Note that adding any sort of file IO to core 0 can cause the boot to fail but I doubt that is the problem here as it looks like there are definitely some steps that are a bit off. 

    As far as the boot mode, we normally try to indicate pin 1 with a small circle so pin 1 is actually on the Ethernet side.

    Let me know how that works out for you but I think you will find it much easier to do.



  • thanks for the quick response.  i just stumbled on the bare metal flashing page after getting stuck in weeds from the yellow warning at the top to review the Creating a Bootable Application page.  I will try that right now....

    a few more quick questions:

    1. what artifact types do i want to set my cores to?
      1. if i am not using the 2nd dsp core and have defined USE_BOTH_CORES_TO_PROCESS_AUDIO  as FALSE, can I get away with setting my core1 as the .ldr?  will there be any other conflicts by settings that to FALSE?
      2. i've tried the following, both unsuccessful (might be missing/mixing some other things too)
        1. core0: executable, core1: executable, core2: loader
        2. core0: executable, core1: loader, core2: executable (default?)
    2. do i want the jumper enabled before i flash the memory/run the batch scripts? what is the concept behind the jumper for flashing?
    3. how can i confirm my silicon revision?
    4. if i am not using core2, can i disable it from each project's 'Project References'?



  • Hi Mike,

    You want all of them set to executables. Once you build and generate your executables you essentially stick them in a folder and run the batch file and you are done.

    USE_BOTH_CORES_TO_PROCESS_AUDIO doesn't have anything really to do with creating the ldr because you can still include core 2 when creating the ldr and it essentially just sits in a while loop if you aren't doing any processing.

    It should not matter if you have the jumper set to flash boot or not when flashing but when cycling power it definitely has to be on. There have been times where the booting application boots into a state where you can't even connect to the processor where you would want to try removing the jumper but I would say that is a rare case.

    Silicon revision is the last thing in the big long string on the chip. Probably 1.0 or 1.2.

    Are you trying to stop core2 from building unnecessarily? I am trying to figure out why you are asking about disabling it. I have always just let it be when I am not using it because it will not affect the processing of the other cores anyway.



  • I got it to work with the batch files!...not sure what i was doing wrong in generating my .ldr stuck in the weeds in the 'recommended' reading haha

    you mention above to set all artifact types to executables, but the 'recommended' documentation says to set your last core to .ldr... maybe thats where I got lost... I'd like to understand a little more deeper if you can clarify where my manual way went wrong...

    thanks again!

  • Hi Mike,

    If you could add a screenshot of your SHARC Loader settings that would help just to see if there is anything you missed. I think you are close to having it working the way your were doing it but my guess is there is some small piece incorrect.



  • thanks for the offer chad.  see attached

    comparing my cldp command (attached in flash_cmd.txt) to the batch file code, i notice a few differences

    • there's stuff about -NoFinalTag and theres an option in the loader exec file settings for that...should i be checking those boxes (seen in screenshot 08) ?
    • batch file uses -format bin argument, but Loader General settings (screenshot 06) is using hex...are those of the same family of settings?

    thanks again!


  • Hi  and  

    I am going to split this into a new thread so it is easier for other members to find.