ADSP-21992 Booting Problem

Hi all,

I have a problem with booting ADSP-21992 from an 8-bit external flash via EMI. When switching on the power supply, VDD_INT and VDD_EXT voltages stabilize on their correct values, the oscillator get stabilized, too and after about 1.5 ms the DSP's internal "power on reset" circuit deasserts the RESET signal. DSP starts to boot the code from the external memory, however, after several hundreds of microseconds it suddenly hangs, letting the bootstrapping unfinished. Then, when I assert and deassert the RESET signal "manually" with a piece of wire, the booting procedure starts again and completes normally, the DSP boots to my program and everything is OK. When I switch to EEPROM >4KB boot, connect an external EEPROM (with the same program) to the SPI bus and boot from it instead of flash, everything goes all right.

During my attempts to fix this problem, I experimented with crystal load capacities bringing it to the state, in which it is not able to start oscillations without some external shock (touching XTAL pin with finger etc.). However, after introducing such a shock and starting the oscillator, the DSP normally booted up even via EMI without need to assert and deassert the RESET signal manually.

I have ADSP-21992BSTZ, 32 MHz external crystal (using DSP's internal TTL oscillator), BYPASS pin unconnected (thus, bypass mode selected via the internal pull-up) and POR connected to the RESET (none other connections to those pins). Power supplies are soft-start DC/DC convertors.

Any guess what to do?

Viktor

Attachments:

por1 - switching on power supplies; pink - VDD_INT, violet - VDD_EXT, yellow - CLK_IN, green - POR (scale: 1 ms - 1 V)

por2 - address bus activity after deasserting the RESET signal by POR

por3 - address bus activity after asserting and deasserting the RESET signal again, but manually

attachments.zip
  • Hi,

    I don't have a solution but I wanted to ask you if you could perform a test.

    Is VDD_INT derived from VDD_EXT? It seems so, since the VDD_EXT is seen taking a dip just as VDD_INT comes on.

    If so, could you try to make VDD_EXT rise more quickly, such that it doesnt dip when VDD_INT comes on? If you can, connect an external power supply to VDD Ext, with a faster turn-on time.

    Regards

    Klaus

  • Hi,

    thank you for the advice. I tried to connect VDD_INT and VDD_EXT directly to my dual lab linear power supply, but the result is the same. Unlike the power supply of my PCB (MAX 1775 dual step-down), it rises both voltages simultaneously, but even slower (about 10 milliseconds). So, I will try to obtain some quicker power supply for the next testing.

    Is there some technical note about powering ADSP-21992? I followed the datasheet for the design purposes, but no specification is given for the power voltages rise time, only a remark that they should be provided either simultaneously or VDD_INT first and then the VDD_EXT, what is fullfilled in both cases.

    Yes, you are right - MAX 1775 takes its higher output and uses it as an input for the lower output step-down block, so VDD_INT is derived from VDD_EXT.

    I don't see any "parasitic" signals from other devices connected to the DSP bus during the startup phase and the number of bytes read via EMI after that the DSP hangs is always exactly the same: 42 (according to the bus activity monitoring).

    Regards

    Viktor

  • Hi!

    So, I tried to use a quick power supply (100 us startup time, 2x ADP3338 - the same, as on the ADI's Starter Kit) and the problem still remains. There is no change whether both the voltages are switched on simultaneously, VDD_EXT first and then VDD_INT or vice versa.

    Are there some pins on the DSP, on which a special care should be taken or which can affect booting via EMI? I.e. which definitely must be pulled up or down during the booting sequence from 8bit EMI? Because - once again - this problem appears only during the booting from the external 8bit Flash via EMI, not during the booting via SPI.

    Regards

    Viktor

    P.S.: I forgot to note that this problem appeared in the new version of our device, where one write-only SPI IC was added on the DSP's bus (i.e. to SPI_CLK, MOSI and GND), however, no activity from it can be seen during booting.

  • Hi Viktor,

    Apologies for the delay in response.

    The ideal power on sequence is to power up all the supplies simulataneosly. If there is some delay, VDDINT has to be powered first followed by VDDEXT. Since you have mentioned that the issue is seen with both these methods, we will have to debug further to find out what else could be going wrong in the system.

    In the existing setup, can you probe the signal at the CLKOUT pin of the DSP ? The peripheral clock(HCLK) is supplied at the CLKOUT pin. For the case the booting hangs (i.e. without issuing manual /RESET), do you see a stable signal of correct frequency at the CLKOUT pin ?

    In the first post, you had mentioned that there were some issues with the crystal oscillator start-up and an external shock is required to fix this issue. Is this crystal start-up issue seen everytime during power-up or only once in a while ? Also, you have mentioned that once the CLKIN issue is fixed, the EMI booting happens as expected and there is no hang. Just for debugging purpose, can you try with a different crystal (with a lower CLKIN value say 25MHz) and check if that helps to resolve the problem ? Also, you can try with an oscillator that provides direct CLKIN to the DSP (the XTAL pin needs to be left unconnected. This will help us to know if the problem is specific to the crystal.

    Please refer to our ADSP-21992 datasheet and the Hardware Reference Manual that has the recommendations for the unused pins of the DSP. Specifically, if the ACK pin is not used in the system, it needs to be pulled "HIGH". It would be helpful if you can post your circuit schematics showing the DSP and the other components used in the system. I would like to review the same.

    Best Regards,

    Vishwanathan

  • Hello!

    CLKOUT doesn't show any irregularities since its stabilization. In the moment of booting the CLKOUT is stable, as well as in the moment of booting malfunction and afterwards.

    I tried to replace the crystal for the 24 MHz one, but the problem persists. The behaviour is the same even when using an external TTL oscillator instead of the crystal (XTAL pin left unconnected, oscillator output connected directly to the CLKIN pin) - right after 42 memory reads the booting stops.

    Pulling the ACK pin high or low doesn't affect this. The care of unused pins was taken upon the datasheet recommendations and the Starter Kit schematic.

    I can send you a private message with the schematic attached.

    Thank you for the advices given.

    Regards

    Viktor