Post Go back to editing

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

  • Hi all!

    The problem is solved. The reason is in the ADSP-21992 - it seems to have poorely designed power-on-reset, which deasserts the RESET# signal too early (after 1.5 ms). Probably, it has nothing to do with external oscillator stabilization nor external power supplies stabilization, but with some chip's internal issues.

    Now I use a simple RC driven (RC=10 ms) TTL gate in place of power-on-reset and it works well.

    For ADSP-21992 applications I strongly recommend to use an external power-on-reset circuit and external TTL oscillator instead of the internal ones.

    Thanks all for help and advices given.

    Viktor

  • hello Viktor,

    It is fortunately for me to discover this topic.When I used the internal power-on reset circuit which is used by

    connecting the POR pin to the RESET pin,I am encountering the same problem.

    You mentioned that we can use a simple RC driven (RC=10 ms) TTL gate,I want to know the accurate value of R and C.


    Many thanks in advance. I hope to hear from you soon.

    Mengduoster


  • Hi,

    the solution I proposed in my last post worked only on some boards, not all of them. Usage of some power-on-reset IC would be probably better. The reason of this problem is still unknown for me.

    I have to point out, that there were two problems connected with booting - one was with oscillator start and the other with a malfunction of the booting procedure which has already successfully started (probably not affected by the oscillator). If you are encountering the former, then usage of an external TTL oscillator is the best solution (or you can experiment with load capacitors if you use an internal oscillator, i.e. decrease their value or even remove one of them).

    Regards

    Viktor

  • This question has been closed by the EZ team and is assumed answered.