Reply by grou...@demmel.com●July 4, 20122012-07-04
This was exactly what I've mentioned in my first reply to you ;-)
It's a mapping issue - but I have to confess that I did not know that
the JTAG routines do the mapping of the vector table by them-selfs ...
Have fun
Herbert
Am 03.07.2012 20:00, schrieb Triffid Hunter: > On Tue, Jul 3, 2012 at 9:17 PM, cfbsoftware1
wrote:
>> See if FlashMagic works better - that might give you some clues as to what
the problem is.
> FlashMagic can indeed read the memory properly, I'm lucky that it
> works in wine :)
>
> I fed FlashMagic through a socat pty to log what it does.
>
> FlashMagic downloads some code into the device's ram and runs it
> before reading the first 512 bytes of flash, and downloads and runs
> some slightly different code before reading the 2nd 512 bytes of
> flash, like this:
>
> W 268435968 16
> 0`DA/\`$!`6!P1P``0,`/0%V[
> 1010
> U 23130
> G 268435968 T
> R 0 512
> OK
>
> W 268435968 16
> 0`DA/\``!`6!P1P``0,`/0#0^
> 1009
> U 23130
> G 268435968 T
> R 512 512
> OK
>
> It appears that this code enabled and disabled the bootrom remapping,
> as mentioned in section 33.6.1 of the user manual - buried in the
> JTAG/SWD section and not mentioned anywhere in section 32- ISP/IAP.
>
> For anyone curious, here's the disassembly (comments are mine, gcc
> isn't that smart!):
>
> ( to disable boot rom mapping and allow reading of flash bytes 0-512)
> 0: 4802 ldr r0, [pc, #8] ; (0xc) // load MEMMAP address into
r0
> 2: f04f 0101 mov.w r1, #1 // load 0x1 into r1 (0x1
> = user flash at address 0)
> 6: 6001 str r1, [r0, #0] // store contents of r1 at
r0
> 8: 4770 bx lr // return
> a: 0000 movs r0, r0 // nulls for word alignment
> c: c040 stmia r0!, {r6} // this is actually
> address 0x400FC040 - "MEMMAP"
> e: 400f ands r7, r1 // this is actually
> address 0x400FC040 - see user manual section 33.6.1
>
> (to re-enable boot rom mapping)
> 0: 4802 ldr r0, [pc, #8] ; (0x1c) // load MEMMAP address into
r0
> 2: f04f 0100 mov.w r1, #0 // load 0x0 into r1 (0x0
> = boot rom at address 0)
> 6: 6001 str r1, [r0, #0] // store contents of r1 at
r0
> 8: 4770 bx lr // return
> a: 0000 movs r0, r0 // nulls for word alignment
> c: c040 stmia r0!, {r6} // this is address
0x400FC040
> e: 400f ands r7, r1 // this is address
0x400FC040
>
> thanks everyone, learn something new every day :)
On Tue, Jul 3, 2012 at 9:17 PM, cfbsoftware1 wrote: > See if FlashMagic works better - that might give you
some clues as to what the problem is.
FlashMagic can indeed read the memory properly, I'm lucky that it
works in wine :)
I fed FlashMagic through a socat pty to log what it does.
FlashMagic downloads some code into the device's ram and runs it
before reading the first 512 bytes of flash, and downloads and runs
some slightly different code before reading the 2nd 512 bytes of
flash, like this:
W 268435968 16
0`DA/\`$!`6!P1P``0,`/0%V[
1010
U 23130
G 268435968 T
R 0 512
OK
W 268435968 16
0`DA/\``!`6!P1P``0,`/0#0^
1009
U 23130
G 268435968 T
R 512 512
OK
It appears that this code enabled and disabled the bootrom remapping,
as mentioned in section 33.6.1 of the user manual - buried in the
JTAG/SWD section and not mentioned anywhere in section 32- ISP/IAP.
For anyone curious, here's the disassembly (comments are mine, gcc
isn't that smart!):
( to disable boot rom mapping and allow reading of flash bytes 0-512)
0: 4802 ldr r0, [pc, #8] ; (0xc) // load MEMMAP address into r0
2: f04f 0101 mov.w r1, #1 // load 0x1 into r1 (0x1
= user flash at address 0)
6: 6001 str r1, [r0, #0] // store contents of r1 at r0
8: 4770 bx lr // return
a: 0000 movs r0, r0 // nulls for word alignment
c: c040 stmia r0!, {r6} // this is actually
address 0x400FC040 - "MEMMAP"
e: 400f ands r7, r1 // this is actually
address 0x400FC040 - see user manual section 33.6.1
(to re-enable boot rom mapping)
0: 4802 ldr r0, [pc, #8] ; (0x1c) // load MEMMAP address into r0
2: f04f 0100 mov.w r1, #0 // load 0x0 into r1 (0x0
= boot rom at address 0)
6: 6001 str r1, [r0, #0] // store contents of r1 at r0
8: 4770 bx lr // return
a: 0000 movs r0, r0 // nulls for word alignment
c: c040 stmia r0!, {r6} // this is address 0x400FC040
e: 400f ands r7, r1 // this is address 0x400FC040
thanks everyone, learn something new every day :)
Reply by cfbsoftware1●July 3, 20122012-07-03
--- In l..., Triffid Hunter wrote: >
> On Tue, Jul 3, 2012 at 12:07 AM, wrote:
>
> > Which tool are you using for ISP ??
> > I'm doing it by hand with a serial terminal, following the instructions
in
> the lpc17xx user manual to the letter.
>
Are you wearing a hairshirt while you do it ;-) See if FlashMagic works better -
that might give you some clues as to what the problem is.
Chris.
Reply by Triffid Hunter●July 3, 20122012-07-03
On Tue, Jul 3, 2012 at 12:07 AM, wrote:
> Which tool are you using for ISP ??
>
I'm doing it by hand with a serial terminal, following the instructions
in
the lpc17xx user manual to the letter.
Reply by grou...@demmel.com●July 2, 20122012-07-02
Which tool are you using for ISP ??
Try to use Flash Magic, I think this should be ok.
Herbert
Am 02.07.2012 15:43, schrieb Triffid Hunter: > On Mon, Jul 2, 2012 at 6:22 PM, cfbsoftware1
wrote:
>
>> --- In l..., Triffid Hunter wrote:
>>> I haven't mapped anything, this is using the built-in on-chip ISP
ROM
>>> that's activated when P2.10 is held low during reset on a blank
chip.
>>>
>> ISP or IAP? If you really mean ISP then check your Code Read Protection
>> setting.
>
> The chip is fresh from my local distributor.
>
> I did look at the CRP settings, but it says that an 'Erase all'
command
> should erase any standing CRP. I have erased the whole chip several times
> (E 0 29) while experimenting with this issue.
>
> It turns out that my flash writes succeed since my application runs
> perfectly, I just find it bizarre that I can't read the first 512 bytes
of
> flash (and thus can't verify the first [and most important] sector)
using
> the built-in ISP.
>
Reply by Triffid Hunter●July 2, 20122012-07-02
On Mon, Jul 2, 2012 at 6:22 PM, cfbsoftware1 wrote:
> --- In l..., Triffid Hunter
wrote:
> >
> > I haven't mapped anything, this is using the built-in on-chip ISP
ROM
> > that's activated when P2.10 is held low during reset on a blank
chip.
> > ISP or IAP? If you really mean ISP then check your Code Read Protection
> setting. The chip is fresh from my local distributor.
I did look at the CRP settings, but it says that an 'Erase all'
command
should erase any standing CRP. I have erased the whole chip several times
(E 0 29) while experimenting with this issue.
It turns out that my flash writes succeed since my application runs
perfectly, I just find it bizarre that I can't read the first 512 bytes
of
flash (and thus can't verify the first [and most important] sector)
using
the built-in ISP.
Reply by cfbsoftware1●July 2, 20122012-07-02
--- In l..., groups@... wrote: >
> Sorry, I was talking about IAP, not ISP - my fault!
> Herbert
>
In that case, check that you have made allowances for all the precautions in
Application Note AN11071 "In-Application Programming for the LPC1700"
Reply by grou...@demmel.com●July 2, 20122012-07-02
Sorry, I was talking about IAP, not ISP - my fault!
Herbert
Am 02.07.2012 07:41, schrieb Triffid Hunter: > On Sun, Jul 1, 2012 at 9:57 PM,
wrote:
>
>> possibly you have mapped the vector table (default address 0x0, length
>> 256 byte) to RAM by setting VTOR (address 0xE000ED08) accordingly.
>> Set VTOR to 0 and try again.
>
> I haven't mapped anything, this is using the built-in on-chip ISP ROM
> that's activated when P2.10 is held low during reset on a blank chip.
>
Reply by cfbsoftware1●July 2, 20122012-07-02
--- In l..., Triffid Hunter wrote: >
> I haven't mapped anything, this is using the built-in on-chip ISP ROM
> that's activated when P2.10 is held low during reset on a blank chip.
>
ISP or IAP? If you really mean ISP then check your Code Read Protection
setting.
> possibly you have mapped the vector table (default
address 0x0, length
> 256 byte) to RAM by setting VTOR (address 0xE000ED08) accordingly.
> Set VTOR to 0 and try again. I haven't mapped anything, this is using the built-in on-chip ISP
ROM
that's activated when P2.10 is held low during reset on a blank chip.
