Questions about Programming Code into SPI Flash with ADSP21479

Hi Ning,

I understand that you are facing some booting issue in the ADSP-21479 processor. In order to assist you better with this issue please provided the details given below.

1. Can you please clarify that you are using EZ-Kit or custom board?
2. You mentioned, “When I ran the failed DSP under ADZS-USB-ICE and VisualDSP, and when build a project, it always ran by itself but not ran the code part. And sometimes I got following information:”. I can see that you have embedded an image here, but unfortunately I can’t able to view it. Can you please attach the image again?
3. I can see in your “Loader Config1.png” that you are not using the default kernal while generating the ‘Loader(.ldr)’ file. Can you please provide the details about the modified Kernal file that you have used?
4. Can you please try booting the processor using the Loder file which generated in ‘debug’ active configuration mode (In ‘Release’ mode VDSP builds a project with optimization enabled.)

If you are using custom board, so in order to investigate this issue can you please do the following debugging steps.

1. Boot Configuration Select pins (BOOT_CFG2–0) select the boot mode for the processor. The BOOT_CFG pins must be valid before RESET (hardware and software) is de-asserted. Please check  the custom board to make sure that the boot configuration pins are set properly for SPI master booting. The Boot Mode Selection table is given below.                                                                                                                   
2. Ensure that the /TRST signal of the JTAG ICE is connected to board ground. Do not leave this signal floating. Letting this signal float may cause boot failures or other memory access failures.
3. Ensure that you have selected the correct parameters while generating the .LDR file. Selecting an inappropriate parameter may cause the boot to fail. Ensure that the correct boot kernel is used before generating the loader (.LDR) file. If you are using a modified boot kernel, try using the default boot kernel supplied with VisualDSP++ together with an example application (like flag toggle) to confirm basic boot-loading.
4. Verify the Power-Up Sequencing timing diagram which is mentioned in the ADSP-21479 datasheet. And make sure that is the processor is properly coming out of RESET.
5. Make sure that the PLL is configured correctly. The default boot kernel may have the PLL configuration as per the EZ-KIT Lite board. This need to be changed if your application uses a different CLKIN. Check the CLKCFG signals and ensure that the PLL is not overdriven. Ensure that the ratio selected in combination with the CLKIN frequency does not exceed the core clock to a value greater than specified.

Thanks & Regards
Jithul

Hi Jithul,

Thank you very much for answering my question about DSP code programming.(I just saw your email when I checked my question here; I wonder why I haven't received an email notice for your answer.)

According to your points, let me introduce the context of my DSP programming. My test code is written by C (and use asm("nop") inside) and my code is run for our own DSP board (ADSP 21479) (in my last post about the questions, I attached a simple checking code just for checking if the code was programmed); we set BOOT_CFG2-0 as 001; the /TRST is grounded per a 4.7K res on the board; the Power On DSP_Reset is generated by a uC on another board, and it is different from the one in the ADSP21479 datasheet, and it doesn't match the timing of Power On Reset in the datasheet per my understanding, but it works well for our production code so far; on my Test Fixture for testing the DSP board, we add a 10-inch no shielded JTAG cable and it is connected to your JTAG cable (11-inch) from ADZS-USB-ICE.

My questions are followed:

1. I generated the Loader file according the configurations listed in the attached file, these configuration are correct? Especially I didn't use the default Kernel but the 479_spi.dxe currently, is it correct?(Besides, some times I selected Debug and sometimes Release, what is the difference between the both? and what is the difference between the format Hex and Binary?)

2. I read some article that said the length of the JTAG was limited. In my test fixture, the JTAG cable from your ADZS-USB-ICE is about 11 inches (seems shielded), and our one is about 10 inches (not shielded); is the JTAG connection is too long to affect the programming? If it is, what is the ideal length of our JTAG cable. Would you please give me suggestion to the JTAG connection with the ADZS-USB-ICE?

3. In another attachment, there are the diagrams that list the timings of our current Power On DSP-Reset, SPI Clk, SPI Flash Data_out and the pulses generated by Flag0 when the checking code could be run. The three pictures showed the same DSP board at multiple power on tests. My question is the current Power On DSP-Reset would affect the DSP booting? (I also plan to do some check for this.)

4. The third attachment lists the information from Visual DSP++, when I applied the bad programmed DSP board with it. What do these information mean?

Should you need any other information or files about my questions, please let me know.

Thanks a lot for answering so many new questions in advance,

Ning Fu

Hi Ning ,

Thanks for further details. Please find my answers given below

1) I generated the Loader file according the configurations listed in the attached file, these configuration are correct? Especially I didn't use the default Kernel but the 479_spi.dxe currently, is it correct?(Besides, sometimes I selected Debug and sometimes Release, what is the difference between the both? and what is the difference between the format Hex and Binary?)

>> The information given in the attached document ‘Configurations for building Loader file for ADSP21479.docx’ looks fine. But I can see an obvious mistake in the first image, where the Target Type option selected as “Executable file”. For generating the loader file the type should be selected as “Loader file”.

I can see in your test code that you have used the CLKIN of 25MHz and configured the PLL to generate the CCLK of 150MHz (where the PLLM value is 6). But in the EZ-Kit, the CLKIN is used as 16.625MHz. In the default Boot Kernel(479_spi.dxe) the PLL is configured to generate the CCLK value of 266MHz using the PLLM value of 16. So if you are using the default boot kernel in your custom design the PLL will be over-driven. Thus you need to modify the boot kernel according to your CLKIN.

Also, can you please provide the information about Core to CLKIN Ratio (CLK_CFG1–0) configured. Check the CLKCFG signals and ensure that the ratio selected in combination with the CLKIN frequency does not exceed the core clock to a value greater than specified.

The difference between binary and Intel hex loader file is already discussed in another thread in the forum, please look into the thread given below.

https://ez.analog.com/message/8083#8083

The difference between Debug and release mode are discussed in the flowing thread, please have a look at it.

https://ez.analog.com/message/9170#9170

2) I read some article that said the length of the JTAG was limited. In my test fixture, the JTAG cable from your ADZS-USB-ICE is about 11 inches (seems shielded), and our one is about 10 inches (not shielded); is the JTAG connection is too long to affect the programming? If it is, what is the ideal length of our JTAG cable. Would you please give me suggestion to the JTAG connection with the ADZS-USB-ICE?

>> As far as my understanding is concerned, you have to buffer your target if the worst-case route distance between the "JTAG emulator header and the DSP" is greater than six (6) inches, regardless of the number of DSPs in the scan chain path. But I am not well aware of the restriction in lenght of the JTAG cable. We have an application note (EE-68) which provides technical information to properly design a JTAG emulator interface for Analog Devices digital signal processors (DSPs) targets. You can download the application note via the link given below.

https://www.analog.com/static/imported-files/application_notes/ee-68.pdf

3) In another attachment, there are the diagrams that list the timings of our current Power On DSP-Reset, SPI Clk, SPI Flash Data_out and the pulses generated by Flag0 when the checking code could be run. The three pictures showed the same DSP board at multiple power on tests. My question is the current Power On DSP-Reset would affect the DSP booting? (I also plan to do some check for this.)

>> Improper Power-Up Sequencing  could affect the booting of the processor. Here I have attached the Power-Up Sequencing timing diagram for ADSP-21479 processor (same is given in the page no 26 / 76 of the datasheet). Can you please provide the screenshots of Power-Up Sequencing (/RESET, VDDINT, VDDEXT, CLOCKIN, CLK_CFG1-0 and /RESETOUT) of your custom board. Please make sure that the power-up sequence requirements needed for the processor is taken care as per the attachment.

4) The third attachment lists the information from Visual DSP++, when I applied the bad programmed DSP board with it. What do these information mean?

>> Can you please confirm these errors are only happening for ‘bad programmed DSP board’. I have seen the error [Failed to set automatic breakpoint at "main"] in past when the PLL is programmed with PLLM and N values accidently which produce the CCLK more than what is supported by the processor. Make sure that the power-up sequencing is proper and the processor is properly coming out of RESET.

Thanks & Regards

Jithul

Hi Jithul,

Thank you so much for giving the detailed explanation for my question. I just checked the hardware configuration of the DSP board and my test fixture. Now I list the checking result and the questions with them according to the order of your explanations:

1. In my Loader configuration I selected "Loader File" (that wrong picture in the file was form other place I didn't check, sorry about it.). For the CLK_CFG1–0, we set as 00, so the Core to CLKIN Ratio should be 8:1; in this situation, do I need to modified the Kernel file (479_spi)? If I need, would you please give me some guide do that? (I found the 479_spi.asm, but I haven't reached the assembly language of the ADSP so far.)

2. I am reading the EE Note 68. Because I don't use any buffer for the JTAG connection path in my TF, and our JTAG cable to the Emulator JTAG header is about 10 inches, I'd better to shorten it less than six inches. Do you think it's necessary?

3. I tested the timing of VDDEXT, VDDINT, DSP_Reset and CLKIN and paste them in the attached file (I couldn't get /RESETOUT, because there is no lead to the the pin on our DSP board.) On our DSP board, the real DSP_Reset is delayed about 300 mS after power on, and according the datasheet, the tCLKRST and tPLLRST should be zero, that may affect the boot processing, but I don't know what happens when the real DSP_Reset comes. Any idea about it? Besides, I want to see what happens if the DSP_Reset starts at Power On. In fact, we have a RC circuit for the reset at power on, the fourth picture on the attached files shows the timing of the both; you can see the reset is pretty slope (not good raising edge); my question is: do I need  something like Schmitt-trigger Inverter to improve the signal?

4. I have used the VisualDSP++ and Emulator (ADZS-USB-ICE) for about two years. The VisualDSP info with the bad programmed board (showed in the attachment I posted last time) could be just seen recently (if my memory is ok) when I checked the DSP programming. In fact, most frequently, the VisualDSP just not build the project properly when add the bad programmed board on my TF. When I build a project with the board (even for Executable File), it always starts by itself but not performs the built code as the picture I put in another attached file. Any comment for this phenomenon? Or you need more information about it?

Should you need any other information or files, please let me know.

Thanks again,

Ning

Hi Ning,

Thank you for giving more details. Please find my answers given below.

1) For the CLK_CFG1–0, we set as 00, so the Core to CLKIN Ratio should be 8:1; in this situation, do I need to modified the Kernel file (479_spi)? If I need, would you please give me some guide do that? (I found the 479_spi.asm, but I haven't reached the assembly language of the ADSP so far.)

>> Since your CLKIN is 25MHz, the selected Core to CLKIN Ratio (8:1) should be fine. This ensure that the PLL is not over-driven the core clock to a value greater than specified. However you have to modify the PLL initialization in the Kernel file (479_spi). For changing the PLL configuration in the kernel file (under “_initPLL:” section) for the desired Core clock frequency, you have to modify the values of ‘PLLM, PLLD, INDIV’ bits in the PMCTL register.

BTW, the processor can boot properly if the PLL is not configured in the Kernel file. Because, on power-up the CLK_CFG1–0 pins are used to select core to CLKIN ratio. So you can try even commenting out the “#define EXT_MEMORY” line in the ‘479_spi.asm’ file which will bypass the initPLL and InitSDRAM sections.

2) I am reading the EE Note 68. Because I don't use any buffer for the JTAG connection path in my TF, and our JTAG cable to the Emulator JTAG header is about 10 inches, I'd better to shorten it less than six inches. Do you think it's necessary?

>> I don’t think shortening the JTAG cable to the Emulator JTAG header is necessary ( you mentioned it is about 10 inches). Because Figure 8  in the application note (EE-68) shows series terminating resistors for the TDO and EMU~ signals going to the JTAG emulator. These resistors are optional. Use terminators if the TDO or EMU~ routes are longer than 6 inches between the “DSP and the JTAG emulator header”. Here it is specifying only the trace length between the DSP and the JTAG emulator header, not the cable length. But please ensure that the same procedure given in the EE-68 note is followed for the JTAG interfacing in the custom board.

3) I tested the timing of VDDEXT, VDDINT, DSP_Reset and CLKIN and paste them in the attached file (I couldn't get /RESETOUT, because there is no lead to the the pin on our DSP board.) On our DSP board, the real DSP_Reset is delayed about 300 mS after power on, and according the datasheet, the tCLKRST and tPLLRST should be zero, that may affect the boot processing, but I don't know what happens when the real DSP_Reset comes. Any idea about it? Besides, I want to see what happens if the DSP_Reset starts at Power On. In fact, we have a RC circuit for the reset at power on, the fourth picture on the attached files shows the timing of the both; you can see the reset is pretty slope (not good raising edge); my question is: do I need  something like Schmitt-trigger Inverter to improve the signal?   

>> While looking at your attached screenshot document, I can see that you are violating the power up sequence given in the datasheet. Here we cannot guarantee the behaviors of the processor, it may be unexpected. After power on the processor the DSP_RESET is delayed about 300 mS in your system, it is not acceptable. As mentioned in the datasheet the time for “RESET Low Before VDD_EXTor VDD_INT On” can be minimum of zero but not lesser than it.

While no specific power-up sequencing is required between VDD_EXT and VDD_INT, there are some considerations that the system designs should take into account.

• No power supply should be powered up for an extended period of time (>200 ms) before another supply starts to ramp up.
• If the VDD_INT power supply comes up after VDD_EXT, any pin, such as RESETOUT and RESET, may actually drive momentarily until the VDD_INT rail has powered up. Systems sharing these signals on the board must determine if there are any issues that need to be addressed based on this behavior.
• Note that during power-up, when the VDD_INT power supply comes up after VDD_EXT, a leakage current of the order of three state leakage current pull-up, pull-down, may be observed on any pin, even if that is an input only (for example, the RESET pin), until the VDD_INT rail has powered up.

4) I have used the VisualDSP++ and Emulator (ADZS-USB-ICE) for about two years. The VisualDSP info with the bad programmed board (showed in the attachment I posted last time) could be just seen recently (if my memory is ok) when I checked the DSP programming. In fact, most frequently, the VisualDSP just not build the project properly when add the bad programmed board on my TF. When I build a project with the board (even for Executable File), it always starts by itself but not performs the built code as the picture I put in another attached file. Any comment for this phenomenon? Or you need more information about it?

>> I am expecting this behaviors is because of the improper power up sequencing of the processor. Once you follow the correct power up sequencing this issue will be resolved.

Thanks & Regards
Jithul

Hi Jithul,

Thank you so much for your detailed explanation and guide to solving my questions about the DSP programming. I am sorry that I didn't reply to you yesterday, because I studied your response and checked the methods in it.

I think I am almost there. Just when I tried to modify the Kernel (479_spi.asm) by bypassing the PLL and SDRAM initiation inside, the assembly code could not pass the project building and I got the information showed in the attachment. And then I found that the original code (I just changed its name and move to my working folder) could not also pass the building. I don't understand the information it showed. I wonder if I lost some thing for building it. Would you please check the file and build it in your VDSP for me?

Thanks a lot in advance,

Ning

Hi Ning,

To bypass the PLL and SDRAM initiation inside the Kernel file (479_spi.asm), you have to only comment the “#define EXT_MEMORY” line in the ‘479_spi.asm’. Please find the attached modified Kernel file (479_spi.asm) for your reference.

While looking at your attached "479_spi_Bypass.asm.zip" file, I feel that you are confused with the word i mentioned before, "bypassing PLL initialization". what I exactly meant by this is 'avoid the PLL & SDRAM initialization fully in the Kernel file'. I can see that you have simply placed the  PLL in 'bypass mode' in your code, and this is not correct. However, instead of doing this if you can configure the correct PLL initialization according to your system CLKIN and desired CCLK frequency (modify the values of ‘PLLM, PLLD, INDIV’ bits in the PMCTL register) in the kernel file, it should be fine.

Please let me know how you get on.

Thanks,

Jithul

Hi Jithul,

Thank you very much for your answer to my question and your modified 479_spi.am (479_spi_modified.asm).

I just ran your code on my VisualDSP++, but it could not pass the File Build and listed the following information:

Would you please check it for me and tell me how I could make the file pass the File Build and Project Build?

Thanks again,

Ning

Hi Ning,

The same kind of issue is already discussed in other thread in the forum, so I would suggest you to have a look at the thread given below.

https://ez.analog.com/message/30197#30197

Please let me know how you get on,

Thanks

Jithul

Hi Jithul,

Thank you for introducing another discussion about the .asm file compiling.

When I moved your .asm file (479_spi_modified.asm) into my project folder. The file could pass the File Build as followed:

but the Project Build (with the file) got error as below:

It's my first time to build a project with a .asm file. I don't what wrong is with the operation. Would you please check it for me? Please let know should you need any file or other information about it.

Thanks again,

Ning