Forums

ADSP 2191 - booting from UART

Started by Unknown September 10, 2003
I have problems booting the ADSP 2191 from the UART (self made
PCB). Initially I transmitt the 0Xaa byte the DPS needs for autobaud
detection to the Rx pin. The chip immediately responds with x4b (ascii
"K") which should have been "OK", but due to a chip error only the "K"
is transmitted. This error is documented by ADI and should not affect
the rest of the boot process.

I continue with no delay to transmit the image.ldr file.

At this point I expect my code to start running, but no success so
far. The code shall continuously send the "b" character out the Tx
pin.

When exactly the same code is downloaded (through USB) on the EZ-Kit
Lite it works fine (the bits are continuously transmitted on the Tx
pin)

I have tried both with and without the initial extra byte in the ldr
file, and I am sure the OPMODE and BMODE[01] pins have the correct
levels for UART boot at the rising edge on /RESET. Inspecting the bit
rate in the "K" response it seems that the autobaud detection was
successful.

Now I am running out of ideas of what it could be. The next thing I
would like to try is to boot the EZ-Kit Lite through the UART. After
setting the OPMODE and BMODE[01] switches into UART boot positions, is
there any reason why this should not be possible ?

I am grateful for any suggestions of what to try.

-- 
Harald Iwe
Harald Iwe <hiwe@broadpark.no> wrote in 
news:m3fzj4bcy1.fsf@localhost.localdomain:

> I have problems booting the ADSP 2191 from the UART (self made > PCB). Initially I transmitt the 0Xaa byte the DPS needs for autobaud > detection to the Rx pin. The chip immediately responds with x4b (ascii > "K") which should have been "OK", but due to a chip error only the "K" > is transmitted. This error is documented by ADI and should not affect > the rest of the boot process. > > I continue with no delay to transmit the image.ldr file. > > At this point I expect my code to start running, but no success so > far. The code shall continuously send the "b" character out the Tx > pin. > > When exactly the same code is downloaded (through USB) on the EZ-Kit > Lite it works fine (the bits are continuously transmitted on the Tx > pin) > > I have tried both with and without the initial extra byte in the ldr > file, and I am sure the OPMODE and BMODE[01] pins have the correct > levels for UART boot at the rising edge on /RESET. Inspecting the bit > rate in the "K" response it seems that the autobaud detection was > successful. > > Now I am running out of ideas of what it could be. The next thing I > would like to try is to boot the EZ-Kit Lite through the UART. After > setting the OPMODE and BMODE[01] switches into UART boot positions, is > there any reason why this should not be possible ? > > I am grateful for any suggestions of what to try. >
We have been booting the 2191 via the UART for over a year. You are right that the autobaud will return just the 'K'. Obviously, the boot config pins are correct since the 'K' works. Do you have the ldr file set to Binary format? What is the clock frequency of the DSP and what baud are you using? I recall that there was a ldr problem with one of the Visual DSP builds. Make sure you have current versions and service packs. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
In article <Xns93F2A857F6BA1aclarkdanvillesignal@66.133.130.30>, 
dsp@danvillesignal.com says...
> Harald Iwe <hiwe@broadpark.no> wrote in > news:m3fzj4bcy1.fsf@localhost.localdomain: > > > I have problems booting the ADSP 2191 from the UART (self made > > PCB). Initially I transmitt the 0Xaa byte the DPS needs for autobaud > > detection to the Rx pin. The chip immediately responds with x4b (ascii > > "K") which should have been "OK", but due to a chip error only the "K" > > is transmitted. This error is documented by ADI and should not affect > > the rest of the boot process. > >
. . .
> I recall that there was a ldr problem with one of the Visual DSP builds. > Make sure you have current versions and service packs. > >
Hi, I had similar problems (although I was booting via SPI). Do you have a JTAG debugger or access to one? I found it very useful for debugging this problem. Load via JTAG and take a memory dump. Then load via UART, jump in with IDE (and JTAG) and take another memory dump. Compare the memory snapshots. The solution to my problem was: - get 219x_loader_1.2.1.2_20021113.zip available from tools errata page (I am using VDSP++ 3.0) - change the timing of when I start to send the bytes (I was 'out by 1' in terms of SPI bus clocks. I had to read the dummy char, wait 8 bits, then start sending... or something along those lines). Spiro -- http://www.mobilecomms.com.au http://www.nexiondata.com
Al Clark <dsp@danvillesignal.com> writes:

> I recall that there was a ldr problem with one of the Visual DSP builds. > Make sure you have current versions and service packs.
At ftp://ftp.analog.com/pub/tools/patches I found a patch called 219x_loader_1.2.2.0_20030721.zip. In the associated documentation it says: Tar 12615 (PR12799) UART boot image has incorrect format After installing this patch everything works OK ! I must say I did not consider this as a possibility. After all the main task of the loader program is to make boot images. But in one out of five or six boot methods it doesn't work. I assumed ADI had done some basic quality assurance before they shipped their software, (VDSP++ 3.0). Many thanks for your help -- Harald Iwe