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.
