Post Go back to editing

ADSP 21489 boot SPI slave with modified kernel, from visual DSP++ to CCES not work.

Hi all,

My problem is quite complicated to explain but I will do my best, do not hesitate to ask information if needed. We were using a program for an ADSP-21489 compiled with visual DSP. This program is load in the DSP using SPI as the DSP is declare as SPI slave. Following this note https://www.analog.com/media/en/technical-documentation/application-notes/EE_177_SHARC_SPI_Slave.Booting.Rev.3.01.07.pdf the default kernel was modified :

at the beginning we define flags and then use these flags to stop our spi transmission from our MCU:
// ==============================================================================
// DEFINE SPI FLAG AND FLAG OUTPUT HERE
#define        SPI_FLAG            FLG0
#define        SPI_FLAG_OUT        FLG0O
// ==============================================================================
 [...]
// ============================== ZERO_LDATA ===================================
// Use core to init 16/32/64-bit internal buffers to zero (saves space in LDR)
//------------------------------------------------------------------------------
ZERO_LDATA:

    I0=R3;      //R3 passes destination address (LW, NW, or SW)
    R0=0;       //Value used to write zero's to memory
    R1=0;       //neighbor register used to write upper 32 bits if LW accesses

    BIT CLR FLAGS SPI_FLAG;        // Indicate busy
    
    LCNTR=R2, DO ZERO_WRITE_END UNTIL lce;      // R2 passes logical word count
ZERO_WRITE_END: DM(I0,M6)=R0;               // write zero to x16, x32, or x64 memory

    BIT SET FLAGS SPI_FLAG;        // Indicate not busy

    JUMP READ_BOOT_INFO;// fetch next section-header
//==============================================================================

//================================  ZERO_L48 ===================================
// Use core to initialize 48/40-bit internal memory to zero
//------------------------------------------------------------------------------
ZERO_L48:
    I0=R3;        //R3 passes destination address
    PX=0;
    
    BIT CLR FLAGS SPI_FLAG;        // Indicate busy
    
    LCNTR=R2, do L48_WRITE_END until lce;
L48_WRITE_END: dm(i0,m6)=PX;

    BIT SET FLAGS SPI_FLAG;        // Indicate not busy
    
    JUMP READ_BOOT_INFO;   // fetch next section-header
//==============================================================================

[...]

    BIT SET FLAGS SPI_FLAG_OUT;     //    make output
    NOP;
    BIT SET FLAGS SPI_FLAG;            // indicate ready
    NOP;

This was working with visual dsp++.

Now that we have migrated on CCES, it impossible to observe the kernel work properly. We modified our program to compile on CCES and it works with jtag ICE-1000 on our dsp. This show the right behaviour, hence we think our .dxe is OK. We also compiled the modified kernel with CCES from the 489_spi project in CCES directories by adding our modifications. Whether it is default kernel or the modified, nothing work and when we observe the flag it doesn't change of state. Hence we think that the kernel is not well load. More than that, we try to just clear this flag in a modified kernel looping on this clear instruction like :

final_init_loop:
    nop;
    BIT SET FLAGS SPI_FLAG_OUT;     //    make output
    NOP;
    BIT CLR FLAGS SPI_FLAG;            // indicate ready
    NOP;
    JUMP final_init_loop;

Even in this situation the flag measured is always high. We can ensure that our measure is ok and that the SPI is sending words to the DSP because we monitor these line with scopes and because with a .ldr from visual DSP++ everything work perfectly. As I said before, .dxe compiled with CCES work perfectly through JTAG in debug mode. Then between the .dxe and the .ldr we feel that there is only the kernel which is concatenated. Is it right or is it more than a concatenation of ldr ?

to sum up :

  • .DXE compiled from CCES works through JTAG ICE-1000.
  • kernel compiles with CCES.
  • SPI from MCU works.
  • same program and kernel work when compiled with VDSP++ and load on our electronic board through SPI.
  • Flag define in modified kernel change of state perfectly when necessary with the final ldr create on VDSP++.
  • Flag doesn't change of state when the final ldr is create with CCES.
  • ldr doesn't work when compiled with CCES as nothing happen on the DSP.
  • Seems that even the kernel boot is not working with the ldr create by CCES.
  • Words in the ldr are observe on MOSI line confirming that SPI is doing the right task.

Do you have any ideas of what could have change between VDSP++ and CCES which can explain a ldr creation modification or a SPI slave behavior ? Is there something we can tried in order to solve this situation ?

Best regards,

Yohann.

Parents
  • Hi Yohann,

    Apologies for the delayed response.

    We would suggest you to refer "ADSP-21479 SPI SLAVE BOOTING" build for CCES available in the below link.Please take this reference and modify for 21489
    ez.analog.com/.../sharc-adsp-21479-spi-slave-boosting

    Can you please provide more information on below points to assist you better on this.

    1.Did you get a chance to connect the Slave board in DND (Do Not Disturb) mode and  This would help to isolate whether the issue is with SPI Slave or the application.?  Please refer the below FAQ for connecting the processor in DND mode.
    ez.analog.com/.../faq-how-to-debug-a-target-board-which-boots-from-flash-using-crosscore-embedded-studio

    2.Can you confirm which version of CCES are you using ?
    3.How you are generating the loader file?
    4.Can you please conform the same application is running properly in Debugging time and Master boot in CCES ?

    Please let us know if you are looking for any other information.

    Regards,
    Anand Selvaraj.

  • Hi M. Selvaraj,

    Finally we found the problem. In debug session, compile the kernel will define the DEBUG word which block the kernel. I'm afraid that it is as simple as that.
    On top of that, it seems that compile a dxe doesn't exploit the whole description of the ldf. Hence, even if our dxe was working, the ldf was wrong for 21489 as I have modified the wrong default ldf example (those when you create a project is different than the one in CCES folders for 21489).
    So, now it works perfectly.

    Thank you again for your time,

    Best regards,

    Yohann.

Reply
  • Hi M. Selvaraj,

    Finally we found the problem. In debug session, compile the kernel will define the DEBUG word which block the kernel. I'm afraid that it is as simple as that.
    On top of that, it seems that compile a dxe doesn't exploit the whole description of the ldf. Hence, even if our dxe was working, the ldf was wrong for 21489 as I have modified the wrong default ldf example (those when you create a project is different than the one in CCES folders for 21489).
    So, now it works perfectly.

    Thank you again for your time,

    Best regards,

    Yohann.

Children