Re: nk.nb0 startup prolems

Thanks! See replies mixed in. I have cut the back end of this as it was
getting
a bit long.

Michael

"Michael Schaffner, P.E." wrote:

> I am sorry for not fully understanding your dilemma. I think what you want
> to do is possible because the build system is very configurable.
>
> First: Are you sure the modifications you are making to your BIB files are
> making it to the flat release directory? That is where MAKEIMG will get what
> it needs to make the NK.BIN.

Yes, I run the "Copy files to release directory" command in the build menu
each
time I make a .bib change. Selecting this option (as opposed to running the
command) in the menu seems to do nothing!
>
> Second: Run VIEWBIN on your NK.BIN and show us the output (1st page).
>

C:\WINCE500\PBWorkspaces\CSB650\RelDir\CSB650_MIPSII_Release>viewbin -r nk.bin
ViewBin... nk.bin
Image Start = 0x80300000, length = 0x0007FF00
Record [ 0] : Start = 0x80300000, Length = 0x00000014, Chksum = 0x0000033C
Record [ 1] : Start = 0x80300040, Length = 0x00000008, Chksum = 0x00000294
Record [ 2] : Start = 0x80300048, Length = 0x00000004, Chksum = 0x000000D4
Record [ 3] : Start = 0x80301000, Length = 0x000515D0, Chksum = 0x013C7B9C
Record [ 4] : Start = 0x803525D0, Length = 0x00000290, Chksum = 0x00012E10
Record [ 5] : Start = 0x80353000, Length = 0x00004F50, Chksum = 0x00150957
Record [ 6] : Start = 0x80357F50, Length = 0x00000054, Chksum = 0x00000E8B
Record [ 7] : Start = 0x80357FA4, Length = 0x00027038, Chksum = 0x0098A800
Record [ 8] : Start = 0x8037F000, Length = 0x00000F00, Chksum = 0x000593B3
Record [ 9] : Start = 0x00000000, Length = 0x80300004, Chksum = 0x00000000
Start address = 0x80300004
Checking record #6 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x80357f50
ROMOFFSET = 0x00000000
Done.

C:\WINCE500\PBWorkspaces\CSB650\RelDir\CSB650_MIPSII_Release>
> Third: What folder are you running CVRTBIN in? Show us the whole command you
> are typing.

C:\WINCE500\PBWorkspaces\CSB650\RelDir\CSB650_MIPSII_Release>cvrtbin -r -a
0x803
00000 -l 0x0007ff00 -w 32 nk.bin
ViewBin... nk.bin
Image Start = 0x80300000, length = 0x0007FF00
Start address = 0x80300004
Checking record #6 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x80357f50
ROMOFFSET = 0x00000000
start 80300000 length 00000014
start 80300040 length 00000008
start 80300048 length 00000004
start 80301000 length 000515d0
start 803525d0 length 00000290
start 80353000 length 00004f50
start 80357f50 length 00000054
start 80357fa4 length 00027038
start 8037f000 length 00000f00
Progress...
0%Done.
>
> Fourth: Have you looked at the help text for CVRTBIN and BIB files and the
> ROMIMAGE tool? There is lots of good info there.
>
Yes, but obviously I have not found the right combination
> Fifth: Have you looked at the help text for the BOOTJUMP and RESETVECTOR
> directives?

I have tried changing BOOTJUMP. My understanding is that it will change the
location of the jump instruction, but not what it jumps to (which is the
whole
problem I am having).

I have read, but not tried RESETVECTOR as I am unsure what to try.

As a reminder, when I run the nk.nb0 image on my board (loaded at address
0xa0300000, uncached, unmapped RAM), the jump goes to 0xa001000c instead
of what I expect, 0xa031000c. I have also tried 0x80300000, and it then jumps
to 0x8001000c.
>
> Sixth: Consider what Steve has suggested for creating an NB0 file. Unless
> the size of your FLASH memory is changing dynamically and varies from
> build-to-build (which would mean your always swapping in different FLASH
> chips), all you need to do is set ROMSIZE once based on the size of your
> FLASH. Have your hardware guys nail this down so you can get to business.
> What I mean is, I am assuming you have a region of FLASH set aside for the
> NK image, so why does the size of the region have to vary from
> build-to-build? Yes, your image size varies based on what your including in
> the build, but you have to account for how big you think it will get and
> work with it. Hope this is not too philosophical... :)

Our situation is that the Flash memory is limited and we will run the image
from
RAM, not Flash. So we store into Flash, copy into ram, then run. Also,
during
development we download directly into ram via ethernet (using our boot
loader).
Since we need to allow different build options, the size is dynamic. The
smaller
the image, the faster the downlod and the less Flash we ultimately use.

>
> --
> Michael Schaffner, P.E.
> Senior Software Engineer
> Windows CE Technical Group
> Applied Data Systems
>
>
>
.

Relevant Pages

  • Re: Confused about Flash
    ... doing the flash and hope the power stays on. ... code from Flash to the RAM, jump to it, and when it is ... copied from the flash to the RAM is on a different adress, ... or that you add to the linker script yourself. ...
    (sci.electronics.design)
  • Re: Confused about Flash
    ... doing the flash and hope the power stays on. ... code from Flash to the RAM, jump to it, and when it is ... copied from the flash to the RAM is on a different adress, ... or that you add to the linker script yourself. ...
    (sci.electronics.design)
  • mc68332 embedded programming problems
    ... I am trying very unsuccessfully to load my code from my Flash into ram, ... and then jump to ram. ... I can only load so many bytes to ram before the system resets. ...
    (sci.electronics.design)
  • Re: mc68332 embedded programming problems
    ... I am trying very unsuccessfully to load my code from my Flash into ram, ... I can only load so many bytes to ram before the system resets. ... just before the jump, but it hangs up when I jump. ...
    (sci.electronics.design)
  • Re: Performance and Flash Pipelining on TI 28F12 DSPs
    ... > of "critical code" we could move to RAM. ... > from internal flash? ... Since the external RAM is as big as the internal flash, ... the timers and all other interrupts are shut off, ...
    (comp.dsp)
Loading