Dear friends,
I have some problems while experimenting with ADSP-21065 EZ-LAB kit. I have an
old version, with RS-232 comms to PC and bundled Visual DSP 4 trial. I realize
that it's rather outdated, but maybe somebody still remembers it..
I want to use a board standalone, so for experiment I'm trying to recompile
one of provided examples as a boot image, specifically this is the Blink
project.
According to the documentation and tips on this forum it's sufficient to
select "loader file" option in project settings and then rebuild it. After the
build succeeds, the blink.ldr file is generated, that is a hex file that
I'm using to program the flash. I program it at both offset 0 and 0x20000
to satisfy any revision of silicon. Unfortunately it does not work.
Is there anything else that needs to be done to prepare such a boot image?
Thanks in advance,
-eh
Boot flash image for ADSP-21065 EZ-LAB
Started by ●September 14, 2010
Reply by ●September 14, 20102010-09-14
Howdy Alexander,
The boot process has two steps. The first step is to load 256
instructions from the flash/boot rom into $20000. That has to
then load the rest of the code you want to run. Here's a note on
some of the details:
http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
and here's one specific to what you are trying to do:
http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
Patience, persistence, truth,
Dr. mike
On Sun, 12 Sep 2010, Alexander Perkalsky wrote:
> Dear friends,
>
> I have some problems while experimenting with ADSP-21065 EZ-LAB kit. I have an old version, with RS-232 comms to PC and bundled Visual DSP 4 trial. I realize that it's rather outdated, but maybe somebody still remembers it..
>
> I want to use a board standalone, so for experiment I'm trying to recompile one of provided examples as a boot image, specifically this is the Blink project.
>
> According to the documentation and tips on this forum it's sufficient to select "loader file" option in project settings and then rebuild it. After the build succeeds, the blink.ldr file is generated, that is a hex file that I'm using to program the flash. I program it at both offset 0 and 0x20000 to satisfy any revision of silicon. Unfortunately it does not work.
>
> Is there anything else that needs to be done to prepare such a boot image?
>
> Thanks in advance,
>
> -eh
The boot process has two steps. The first step is to load 256
instructions from the flash/boot rom into $20000. That has to
then load the rest of the code you want to run. Here's a note on
some of the details:
http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
and here's one specific to what you are trying to do:
http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
Patience, persistence, truth,
Dr. mike
On Sun, 12 Sep 2010, Alexander Perkalsky wrote:
> Dear friends,
>
> I have some problems while experimenting with ADSP-21065 EZ-LAB kit. I have an old version, with RS-232 comms to PC and bundled Visual DSP 4 trial. I realize that it's rather outdated, but maybe somebody still remembers it..
>
> I want to use a board standalone, so for experiment I'm trying to recompile one of provided examples as a boot image, specifically this is the Blink project.
>
> According to the documentation and tips on this forum it's sufficient to select "loader file" option in project settings and then rebuild it. After the build succeeds, the blink.ldr file is generated, that is a hex file that I'm using to program the flash. I program it at both offset 0 and 0x20000 to satisfy any revision of silicon. Unfortunately it does not work.
>
> Is there anything else that needs to be done to prepare such a boot image?
>
> Thanks in advance,
>
> -eh
Reply by ●October 6, 20102010-10-06
Dear Mike,
Thank you for your reply. I consulted both these app. notes and Visual DSP loader documentation. However I still have problems with making it running.
Here is my work sequence:
1. Compile release version of provided Blink project
2. Generate a boot image using one of the following commands:
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -o out1.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -p0x20000 -o out2.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -o out3.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -p0x20000 -o out4.ldr
Here I tried both kernel binaries, one that comes with VisualDSP and one that is supplied on EZ-LAB supplementing diskette. I tried both options with offset 0x20000 and without it.
However none of these images is working. Is there something that I'm doing incorrectly?
Thanks in advance,
Alexander.
--- On Tue, 9/14/10, Mike Rosing wrote:
> Howdy Alexander,
>
> The boot process has two steps. The first step is to
> load 256
> instructions from the flash/boot rom into $20000.
> That has to
> then load the rest of the code you want to run.
> Here's a note on
> some of the details:
> http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
> and here's one specific to what you are trying to do:
> http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
>
> Patience, persistence, truth,
> Dr. mike
Thank you for your reply. I consulted both these app. notes and Visual DSP loader documentation. However I still have problems with making it running.
Here is my work sequence:
1. Compile release version of provided Blink project
2. Generate a boot image using one of the following commands:
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -o out1.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -p0x20000 -o out2.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -o out3.ldr
elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -p0x20000 -o out4.ldr
Here I tried both kernel binaries, one that comes with VisualDSP and one that is supplied on EZ-LAB supplementing diskette. I tried both options with offset 0x20000 and without it.
However none of these images is working. Is there something that I'm doing incorrectly?
Thanks in advance,
Alexander.
--- On Tue, 9/14/10, Mike Rosing wrote:
> Howdy Alexander,
>
> The boot process has two steps. The first step is to
> load 256
> instructions from the flash/boot rom into $20000.
> That has to
> then load the rest of the code you want to run.
> Here's a note on
> some of the details:
> http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
> and here's one specific to what you are trying to do:
> http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
>
> Patience, persistence, truth,
> Dr. mike
Reply by ●October 7, 20102010-10-07
Howdy Alexander,
How are you writing the boot image down to the flash? Can you monitor the
chip select line and the lsb address to see if it is trying to write?
If it is writing, then monitor the chip select, read and lsb address to
see if the processor is actually trying to wake up to the flash. If it
looks like is, then most likely your boot code isn't doing anything
useful.
I don't think you can debug the boot process, but you should be able to
put in a hardware break at 0x20000 and follow the code that does get
loaded. Single step it and see if it looks like the code you expected.
There's a lot that can go wrong here, so taking it one step at a time is a
good idea.
Patience, persistence, truth,
Dr. mike
On Tue, 5 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thank you for your reply. I consulted both these app. notes and Visual DSP loader documentation. However I still have problems with making it running.
>
> Here is my work sequence:
>
> 1. Compile release version of provided Blink project
> 2. Generate a boot image using one of the following commands:
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -o out1.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -p0x20000 -o out2.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -o out3.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -p0x20000 -o out4.ldr
>
> Here I tried both kernel binaries, one that comes with VisualDSP and one that is supplied on EZ-LAB supplementing diskette. I tried both options with offset 0x20000 and without it.
>
> However none of these images is working. Is there something that I'm doing incorrectly?
>
> Thanks in advance,
>
> Alexander.
>
> --- On Tue, 9/14/10, Mike Rosing wrote:
>
>> Howdy Alexander,
>>
>> The boot process has two steps. The first step is to
>> load 256
>> instructions from the flash/boot rom into $20000.
>> That has to
>> then load the rest of the code you want to run.
>> Here's a note on
>> some of the details:
>> http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
>> and here's one specific to what you are trying to do:
>> http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
>>
>> Patience, persistence, truth,
>> Dr. mike
>
How are you writing the boot image down to the flash? Can you monitor the
chip select line and the lsb address to see if it is trying to write?
If it is writing, then monitor the chip select, read and lsb address to
see if the processor is actually trying to wake up to the flash. If it
looks like is, then most likely your boot code isn't doing anything
useful.
I don't think you can debug the boot process, but you should be able to
put in a hardware break at 0x20000 and follow the code that does get
loaded. Single step it and see if it looks like the code you expected.
There's a lot that can go wrong here, so taking it one step at a time is a
good idea.
Patience, persistence, truth,
Dr. mike
On Tue, 5 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thank you for your reply. I consulted both these app. notes and Visual DSP loader documentation. However I still have problems with making it running.
>
> Here is my work sequence:
>
> 1. Compile release version of provided Blink project
> 2. Generate a boot image using one of the following commands:
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -o out1.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ldr\065L_prom.dxe" -p0x20000 -o out2.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -o out3.ldr
> elfloader blink.dxe -bprom -fhex -dADSP-21065L -l "C:\Program Files\Analog Devices\VisualDSP\21k\ADSP21065L EZ-LAB\Kernel\Src\065L_prm.dxe" -p0x20000 -o out4.ldr
>
> Here I tried both kernel binaries, one that comes with VisualDSP and one that is supplied on EZ-LAB supplementing diskette. I tried both options with offset 0x20000 and without it.
>
> However none of these images is working. Is there something that I'm doing incorrectly?
>
> Thanks in advance,
>
> Alexander.
>
> --- On Tue, 9/14/10, Mike Rosing wrote:
>
>> Howdy Alexander,
>>
>> The boot process has two steps. The first step is to
>> load 256
>> instructions from the flash/boot rom into $20000.
>> That has to
>> then load the rest of the code you want to run.
>> Here's a note on
>> some of the details:
>> http://www.analog.com/static/imported-files/application_notes/434925919EE_56_Rev_3.03.07.pdf
>> and here's one specific to what you are trying to do:
>> http://www.analog.com/static/imported-files/application_notes/EE_107.pdf
>>
>> Patience, persistence, truth,
>> Dr. mike
>
Reply by ●October 8, 20102010-10-08
Dear Mike,
Thank you for your reply.
I'm programming the image to the flash using external programmer. I'm pretty sure that it does it well, I was able to program this flash with original EZ-LAB firmware and it works.
This is a hobby project, so I don't have too much test equipment to debug it.
I think that I'm facing more basic problem here. I'm not developing my own code. I'm just trying to create a boot image using provided example and pre-compiled kernel that comes with EZ-LAB. My understanding that this option shall work out of the box, and since it does not I suspect that something is wrong in my operating sequence.
Do I need to modify any other files in my case?
Thanks,
Alexander.
--- On Thu, 10/7/10, Mike Rosing wrote:
> Howdy Alexander,
>
> How are you writing the boot image down to the flash?
> Can you monitor the
> chip select line and the lsb address to see if it is trying
> to write?
>
> If it is writing, then monitor the chip select, read and
> lsb address to
> see if the processor is actually trying to wake up to the
> flash. If it
> looks like is, then most likely your boot code isn't doing
> anything
> useful.
>
> I don't think you can debug the boot process, but you
> should be able to
> put in a hardware break at 0x20000 and follow the code that
> does get
> loaded. Single step it and see if it looks like the
> code you expected.
>
> There's a lot that can go wrong here, so taking it one step
> at a time is a
> good idea.
>
> Patience, persistence, truth,
> Dr. mike
Thank you for your reply.
I'm programming the image to the flash using external programmer. I'm pretty sure that it does it well, I was able to program this flash with original EZ-LAB firmware and it works.
This is a hobby project, so I don't have too much test equipment to debug it.
I think that I'm facing more basic problem here. I'm not developing my own code. I'm just trying to create a boot image using provided example and pre-compiled kernel that comes with EZ-LAB. My understanding that this option shall work out of the box, and since it does not I suspect that something is wrong in my operating sequence.
Do I need to modify any other files in my case?
Thanks,
Alexander.
--- On Thu, 10/7/10, Mike Rosing wrote:
> Howdy Alexander,
>
> How are you writing the boot image down to the flash?
> Can you monitor the
> chip select line and the lsb address to see if it is trying
> to write?
>
> If it is writing, then monitor the chip select, read and
> lsb address to
> see if the processor is actually trying to wake up to the
> flash. If it
> looks like is, then most likely your boot code isn't doing
> anything
> useful.
>
> I don't think you can debug the boot process, but you
> should be able to
> put in a hardware break at 0x20000 and follow the code that
> does get
> loaded. Single step it and see if it looks like the
> code you expected.
>
> There's a lot that can go wrong here, so taking it one step
> at a time is a
> good idea.
>
> Patience, persistence, truth,
> Dr. mike
Reply by ●October 10, 20102010-10-10
Howdy Alexander,
That's a good test - if the original works then you are probably accessing
the flash correctly.
Can you compare the binary data for the source original and the compiled
version of the original? That is, do you have access to the original
EZ-LAB firmware source? then you can compare your compiled version to
what they actually send down.
Does the EZ-lab have any debug capability? Maybe you can halt the
processor and look at its memory after it boots and see what is there.
If it's blank, that's different than if it's got just the vector table.
If you can find any source that works, then your process is ok. If no
source works, then maybe there is missing step. There should be a manual
that describes all the steps, I assume you've looked at it. It could be
there is an undocumented trick.
Patience, persistence, truth,
Dr. mike
On Thu, 7 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thank you for your reply.
>
> I'm programming the image to the flash using external programmer. I'm
>pretty sure that it does it well, I was able to program this flash with
>original EZ-LAB firmware and it works.
>
> This is a hobby project, so I don't have too much test equipment to debug it.
>
> I think that I'm facing more basic problem here. I'm not developing my own code. I'm just trying to create a boot image using provided example and pre-compiled kernel that comes with EZ-LAB. My understanding that this option shall work out of the box, and since it does not I suspect that something is wrong in my operating sequence.
>
> Do I need to modify any other files in my case?
>
> Thanks,
>
> Alexander.
>
> --- On Thu, 10/7/10, Mike Rosing wrote:
>
>> Howdy Alexander,
>>
>> How are you writing the boot image down to the flash?
>> Can you monitor the
>> chip select line and the lsb address to see if it is trying
>> to write?
>>
>> If it is writing, then monitor the chip select, read and
>> lsb address to
>> see if the processor is actually trying to wake up to the
>> flash. If it
>> looks like is, then most likely your boot code isn't doing
>> anything
>> useful.
>>
>> I don't think you can debug the boot process, but you
>> should be able to
>> put in a hardware break at 0x20000 and follow the code that
>> does get
>> loaded. Single step it and see if it looks like the
>> code you expected.
>>
>> There's a lot that can go wrong here, so taking it one step
>> at a time is a
>> good idea.
>>
>> Patience, persistence, truth,
>> Dr. mike
>
That's a good test - if the original works then you are probably accessing
the flash correctly.
Can you compare the binary data for the source original and the compiled
version of the original? That is, do you have access to the original
EZ-LAB firmware source? then you can compare your compiled version to
what they actually send down.
Does the EZ-lab have any debug capability? Maybe you can halt the
processor and look at its memory after it boots and see what is there.
If it's blank, that's different than if it's got just the vector table.
If you can find any source that works, then your process is ok. If no
source works, then maybe there is missing step. There should be a manual
that describes all the steps, I assume you've looked at it. It could be
there is an undocumented trick.
Patience, persistence, truth,
Dr. mike
On Thu, 7 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thank you for your reply.
>
> I'm programming the image to the flash using external programmer. I'm
>pretty sure that it does it well, I was able to program this flash with
>original EZ-LAB firmware and it works.
>
> This is a hobby project, so I don't have too much test equipment to debug it.
>
> I think that I'm facing more basic problem here. I'm not developing my own code. I'm just trying to create a boot image using provided example and pre-compiled kernel that comes with EZ-LAB. My understanding that this option shall work out of the box, and since it does not I suspect that something is wrong in my operating sequence.
>
> Do I need to modify any other files in my case?
>
> Thanks,
>
> Alexander.
>
> --- On Thu, 10/7/10, Mike Rosing wrote:
>
>> Howdy Alexander,
>>
>> How are you writing the boot image down to the flash?
>> Can you monitor the
>> chip select line and the lsb address to see if it is trying
>> to write?
>>
>> If it is writing, then monitor the chip select, read and
>> lsb address to
>> see if the processor is actually trying to wake up to the
>> flash. If it
>> looks like is, then most likely your boot code isn't doing
>> anything
>> useful.
>>
>> I don't think you can debug the boot process, but you
>> should be able to
>> put in a hardware break at 0x20000 and follow the code that
>> does get
>> loaded. Single step it and see if it looks like the
>> code you expected.
>>
>> There's a lot that can go wrong here, so taking it one step
>> at a time is a
>> good idea.
>>
>> Patience, persistence, truth,
>> Dr. mike
>
Reply by ●October 10, 20102010-10-10
Dear Mike,
Thanks again!
The original firmware supplied with the EZ-LAB is a ROM monitor, it works with VisualDSP IDE; it's possible to download and debug the application code on-board, this works for all the sample projects.
The sources of the ROM monitor are not available in the kit.
Basically, what is missing is the step-by step guidelines from Analog how to convert the Visual DSP project into a boot loadable Flash image.
I looked through all available docs but no one describes the full story ..
Thanks,
Alexander.
--- On Fri, 10/8/10, Mike Rosing wrote:
> From: Mike Rosing
> Subject: Re: [adsp] Boot flash image for ADSP-21065 EZ-LAB
> To: "Alexander Perkalsky"
> Cc: A...
> Date: Friday, October 8, 2010, 5:01 PM
> Howdy Alexander,
>
> That's a good test - if the original works then you are
> probably accessing
> the flash correctly.
>
> Can you compare the binary data for the source original and
> the compiled
> version of the original? That is, do you have access
> to the original
> EZ-LAB firmware source? then you can compare your
> compiled version to
> what they actually send down.
>
> Does the EZ-lab have any debug capability? Maybe you
> can halt the
> processor and look at its memory after it boots and see
> what is there.
> If it's blank, that's different than if it's got just the
> vector table.
>
> If you can find any source that works, then your process is
> ok. If no
> source works, then maybe there is missing step. There
> should be a manual
> that describes all the steps, I assume you've looked at
> it. It could be
> there is an undocumented trick.
>
> Patience, persistence, truth,
> Dr. mike
>
Thanks again!
The original firmware supplied with the EZ-LAB is a ROM monitor, it works with VisualDSP IDE; it's possible to download and debug the application code on-board, this works for all the sample projects.
The sources of the ROM monitor are not available in the kit.
Basically, what is missing is the step-by step guidelines from Analog how to convert the Visual DSP project into a boot loadable Flash image.
I looked through all available docs but no one describes the full story ..
Thanks,
Alexander.
--- On Fri, 10/8/10, Mike Rosing wrote:
> From: Mike Rosing
> Subject: Re: [adsp] Boot flash image for ADSP-21065 EZ-LAB
> To: "Alexander Perkalsky"
> Cc: A...
> Date: Friday, October 8, 2010, 5:01 PM
> Howdy Alexander,
>
> That's a good test - if the original works then you are
> probably accessing
> the flash correctly.
>
> Can you compare the binary data for the source original and
> the compiled
> version of the original? That is, do you have access
> to the original
> EZ-LAB firmware source? then you can compare your
> compiled version to
> what they actually send down.
>
> Does the EZ-lab have any debug capability? Maybe you
> can halt the
> processor and look at its memory after it boots and see
> what is there.
> If it's blank, that's different than if it's got just the
> vector table.
>
> If you can find any source that works, then your process is
> ok. If no
> source works, then maybe there is missing step. There
> should be a manual
> that describes all the steps, I assume you've looked at
> it. It could be
> there is an undocumented trick.
>
> Patience, persistence, truth,
> Dr. mike
>
Reply by ●October 10, 20102010-10-10
OK, well I know that one step is to convert the actual boot code into
bytes that get sent in backwards order, but I would think the flash
programmer knows how to do that step.
Check out EE-107, 56, 72 and 77. It looks like there could be several
trip points depending on your version of processor.
One thing you can do is use the rom monitor to burn a new flash, then
you can check the flash before you reboot. If it fails, use the
programmer to put the monitor back in and try a new version of the
boot code. It may be slow, but it will get you there!
In fact, you could use the disassembler to figure out where the monitor
resides and keep that as part of the flash so you can ensure it boots
your code and the monitor too.
Patience, persistence, truth,
Dr. mike
On Fri, 8 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thanks again!
>
> The original firmware supplied with the EZ-LAB is a ROM monitor, it
>works with VisualDSP IDE; it's possible to download and debug the
>application code on-board, this works for all the sample projects.
>
> The sources of the ROM monitor are not available in the kit.
>
> Basically, what is missing is the step-by step guidelines from Analog how to convert the Visual DSP project into a boot loadable Flash image.
>
> I looked through all available docs but no one describes the full story ..
>
> Thanks,
>
> Alexander.
>
> --- On Fri, 10/8/10, Mike Rosing wrote:
>
>> From: Mike Rosing
>> Subject: Re: [adsp] Boot flash image for ADSP-21065 EZ-LAB
>> To: "Alexander Perkalsky"
>> Cc: A...
>> Date: Friday, October 8, 2010, 5:01 PM
>> Howdy Alexander,
>>
>> That's a good test - if the original works then you are
>> probably accessing
>> the flash correctly.
>>
>> Can you compare the binary data for the source original and
>> the compiled
>> version of the original? That is, do you have access
>> to the original
>> EZ-LAB firmware source? then you can compare your
>> compiled version to
>> what they actually send down.
>>
>> Does the EZ-lab have any debug capability? Maybe you
>> can halt the
>> processor and look at its memory after it boots and see
>> what is there.
>> If it's blank, that's different than if it's got just the
>> vector table.
>>
>> If you can find any source that works, then your process is
>> ok. If no
>> source works, then maybe there is missing step. There
>> should be a manual
>> that describes all the steps, I assume you've looked at
>> it. It could be
>> there is an undocumented trick.
>>
>> Patience, persistence, truth,
>> Dr. mike
>
bytes that get sent in backwards order, but I would think the flash
programmer knows how to do that step.
Check out EE-107, 56, 72 and 77. It looks like there could be several
trip points depending on your version of processor.
One thing you can do is use the rom monitor to burn a new flash, then
you can check the flash before you reboot. If it fails, use the
programmer to put the monitor back in and try a new version of the
boot code. It may be slow, but it will get you there!
In fact, you could use the disassembler to figure out where the monitor
resides and keep that as part of the flash so you can ensure it boots
your code and the monitor too.
Patience, persistence, truth,
Dr. mike
On Fri, 8 Oct 2010, Alexander Perkalsky wrote:
> Dear Mike,
>
> Thanks again!
>
> The original firmware supplied with the EZ-LAB is a ROM monitor, it
>works with VisualDSP IDE; it's possible to download and debug the
>application code on-board, this works for all the sample projects.
>
> The sources of the ROM monitor are not available in the kit.
>
> Basically, what is missing is the step-by step guidelines from Analog how to convert the Visual DSP project into a boot loadable Flash image.
>
> I looked through all available docs but no one describes the full story ..
>
> Thanks,
>
> Alexander.
>
> --- On Fri, 10/8/10, Mike Rosing wrote:
>
>> From: Mike Rosing
>> Subject: Re: [adsp] Boot flash image for ADSP-21065 EZ-LAB
>> To: "Alexander Perkalsky"
>> Cc: A...
>> Date: Friday, October 8, 2010, 5:01 PM
>> Howdy Alexander,
>>
>> That's a good test - if the original works then you are
>> probably accessing
>> the flash correctly.
>>
>> Can you compare the binary data for the source original and
>> the compiled
>> version of the original? That is, do you have access
>> to the original
>> EZ-LAB firmware source? then you can compare your
>> compiled version to
>> what they actually send down.
>>
>> Does the EZ-lab have any debug capability? Maybe you
>> can halt the
>> processor and look at its memory after it boots and see
>> what is there.
>> If it's blank, that's different than if it's got just the
>> vector table.
>>
>> If you can find any source that works, then your process is
>> ok. If no
>> source works, then maybe there is missing step. There
>> should be a manual
>> that describes all the steps, I assume you've looked at
>> it. It could be
>> there is an undocumented trick.
>>
>> Patience, persistence, truth,
>> Dr. mike
>
