--- In l..., "acetoel" wrote: >
> Hello,
>
> I have measured the reset pin, it is at 3.3V, and if I pressed the button it
goes to 0V.
>
> In my board, I don't have the Diode connected to VBAT pin. May be this be
a problem when running the code? I think no.
>
> I will try to program your code directly from the Hex file. Thanks very
much.
>
> Ezequiel As to the RTC, if you don't provide power to the device, the user
manual says you have to ground the VBAT pin.
I missed the part in the first message where you mentioned that this board is
your own design.
You have tested Reset, you know the flash is getting programmed, you know the
checksum is correct so the only thing left if P0.14 and it must be high BEFORE
the chip comes out of reset.
You probably have the 100 nF capacitor and 22k resistor on the Reset line but,
if not, that capacitor is what guarantees P0.14 is high before Reset goes
high.
I haven't studied how the JTAG pins need to be pulled up or down but all of
the Olimex boards take care of it. One of the problems of copying a design is
not implementing all of the circuitry because "I don't need it".
At a minimum, I would implement all of the pull-up/pull-down circuitry on the
H2138 header board.
I have measured the reset pin, it is at 3.3V, and if I pressed the button it
goes to 0V.
In my board, I don't have the Diode connected to VBAT pin. May be this be a
problem when running the code? I think no.
I will try to program your code directly from the Hex file. Thanks very much.
Ezequiel
--- In l..., "rtstofer" wrote: >
> --- In l..., "acetoel" wrote:
> >
> > Hello, happy new year.
> >
> > I have all the switches in the OFF position. I hve measured P0.12 and it is
at 3.3V when resetting...and it doesn't go low.
> >
> > If VBAT is left unconnected in a LPC2138, will this be a problem for the MCU
to start?
> > From the schematic, you can see the diode D2 provices 3.3V to the RTC in the
case where a battery is producing less voltage or simply doesn't exist.
>
> Did you measure the RST pin to verify it is at 3.3V when you are trying to
run? If it is at 0V, the device is held in reset.
>
> I have posted in the Files folder LPC2148_Blink.zip. It MAY work for an
LPC2138 because I believe they have the same memory map. The .hex file is
included so you might want to try it.
>
> FWIW, I ran the file on an LPC2148 and verified that P0.12 does alternate.
There is no LED but I used a scope.
>
> Richard
>
Reply by rtstofer●January 1, 20102010-01-01
--- In l..., "acetoel" wrote: >
> Hello, happy new year.
>
> I have all the switches in the OFF position. I hve measured P0.12 and it is at
3.3V when resetting...and it doesn't go low.
>
> If VBAT is left unconnected in a LPC2138, will this be a problem for the MCU
to start?
>
From the schematic, you can see the diode D2 provices 3.3V to the RTC in the
case where a battery is producing less voltage or simply doesn't exist.
Did you measure the RST pin to verify it is at 3.3V when you are trying to run?
If it is at 0V, the device is held in reset.
I have posted in the Files folder LPC2148_Blink.zip. It MAY work for an LPC2138
because I believe they have the same memory map. The .hex file is included so
you might want to try it.
FWIW, I ran the file on an LPC2148 and verified that P0.12 does alternate.
There is no LED but I used a scope.
Richard
Reply by acetoel●January 1, 20102010-01-01
Hello, happy new year.
I have all the switches in the OFF position. I hve measured P0.12 and it is at
3.3V when resetting...and it doesn't go low.
If VBAT is left unconnected in a LPC2138, will this be a problem for the MCU to
start?
--- In l..., "rtstofer" wrote: >
> --- In l..., "acetoel" wrote:
> >
> > No I don't have a JTAG. I tried blinking a led, and loading Olimex.com
examples (so I assume the hex file is well generated). That examples
doesn't work either.
> >
> > So as what you are saying about the first two lines of code... The code is
well loaded, and it must work, without problems..
> >
> So, why do you think you are not coming out of the bootloader? Maybe the
program just doesn't work.
>
> Do you have the jumper installed for the LED?
>
> You are turning the ICSP switch (2) back to the OFF (RUN) position before
resetting the device, right?
>
> You can prevent the PC from being capable of holding the device in reset by
turning OFF switch 1. This means you will have to turn on switch 2 and hit the
reset button before FlashMagic can operate.
>
> I leave both switches in the OFF position and I only move Switch 1 (ICSP/RUN)
to ON when I actually want to reset and program. I NEVER move switch 2. It is
always OFF.
>
> Unfortunately, that example is built by a toolchain I don't use so I
can't really try it. It looks ok but I didn't see the .hex file in
the .zip. Maybe I'm looking in the wrong place.
>
Reply by rtstofer●December 30, 20092009-12-30
--- In l..., "acetoel" wrote: >
> No I don't have a JTAG. I tried blinking a led, and loading Olimex.com
examples (so I assume the hex file is well generated). That examples
doesn't work either.
>
> So as what you are saying about the first two lines of code... The code is
well loaded, and it must work, without problems..
> So, why do you think you are not coming out of the bootloader? Maybe the
program just doesn't work.
Do you have the jumper installed for the LED?
You are turning the ICSP switch (2) back to the OFF (RUN) position before
resetting the device, right?
You can prevent the PC from being capable of holding the device in reset by
turning OFF switch 1. This means you will have to turn on switch 2 and hit the
reset button before FlashMagic can operate.
I leave both switches in the OFF position and I only move Switch 1 (ICSP/RUN) to
ON when I actually want to reset and program. I NEVER move switch 2. It is
always OFF.
Unfortunately, that example is built by a toolchain I don't use so I
can't really try it. It looks ok but I didn't see the .hex file in
the .zip. Maybe I'm looking in the wrong place.
Reply by acetoel●December 30, 20092009-12-30
No I don't have a JTAG. I tried blinking a led, and loading Olimex.com
examples (so I assume the hex file is well generated). That examples
doesn't work either.
So as what you are saying about the first two lines of code... The code is well
loaded, and it must work, without problems..
--- In l..., "rtstofer" wrote: > > Your vectors are:
> >
> > > 00000000 18F09FE5 18F09FE5 18F09FE5 18F09FE5 ................
> > > 00000010 18F09FE5 845F20B9 F0FF1FE5 14F09FE5 .....
> >
> > E59FF018 - unwrap the little endian stuff
> > E59FF018
> > E59FF018
> > E59FF018
> > E59FF018
> > B9205F84
> > E51FFFF0
> > E59FF014
> > =========> > 7 00000000 = 0, ignore the carry
> >
> > The total of the first 8 words must be 0x00000000 for the bootloader to
assume there is a valid program loaded.
> >
> > Richard
>
> All of which means that if you can't get out of the bootloader, it
isn't because of the checksum. The other condition is P0.14 (assuming
it's a chip I know about) and that must be high coming out of reset.
>
> You might read the section on the Flash Memory System and Programming. P0.14
is only one thing that can hang you up. There may be others having to do with
JTAG. But, since I don't use JTAG, I don't know what they might
be.
>
> Or, you could be getting out of the bootloader and the program simply
doesn't work. Are you trying to trace the program with a JTAG debugger?
>
> Richard
>
>
Reply by rtstofer●December 30, 20092009-12-30
> Your vectors are:
>
> > 00000000 18F09FE5 18F09FE5 18F09FE5 18F09FE5 ................
> > 00000010 18F09FE5 845F20B9 F0FF1FE5 14F09FE5 .....
>
> E59FF018 - unwrap the little endian stuff
> E59FF018
> E59FF018
> E59FF018
> E59FF018
> B9205F84
> E51FFFF0
> E59FF014
> =========> 7 00000000 = 0, ignore the carry
>
> The total of the first 8 words must be 0x00000000 for the bootloader to assume
there is a valid program loaded.
>
> Richard
All of which means that if you can't get out of the bootloader, it
isn't because of the checksum. The other condition is P0.14 (assuming
it's a chip I know about) and that must be high coming out of reset.
You might read the section on the Flash Memory System and Programming. P0.14 is
only one thing that can hang you up. There may be others having to do with
JTAG. But, since I don't use JTAG, I don't know what they might
be.
Or, you could be getting out of the bootloader and the program simply
doesn't work. Are you trying to trace the program with a JTAG debugger?
Richard
>
Reply by rtstofer●December 30, 20092009-12-30
--- In l..., "acetoel" wrote: >
> Thanks Richard...
>
> > Now, if you break out the first 8 words and add them up, they should total
0x00000000.
>
> ...what?
>
> Thanks!
> --- In l..., "rtstofer" wrote:
> >
> >
> >
> > --- In l..., "acetoel" wrote:
> > >
> > > In the Hex file generated by the compiler (GNUARM) I see this
> > >
> > >
> > > :1000000018F09FE518F09FE518F09FE518F09FE5C0
> > > :1000100018F09FE50000A0E1F0FF1FE514F09FE558
> > >
> > > There is a 0x00 at 0x14, but when I program the MCU, in the memory dump I
see somethings different from 0x14 to 0x17
> >
> > That's good because your programmer calculated and inserted the
checksum for you.
> >
> > Now, if you break out the first 8 words and add them up, they should total
0x00000000.
> >
> > I didn't try that.
> >
> > Richard
>
E59FF018 - unwrap the little endian stuff
E59FF018
E59FF018
E59FF018
E59FF018
B9205F84
E51FFFF0
E59FF014
=========7 00000000 = 0, ignore the carry
The total of the first 8 words must be 0x00000000 for the bootloader to assume
there is a valid program loaded.
Richard
Reply by acetoel●December 30, 20092009-12-30
Thanks Richard...
> Now, if you break out the first 8 words and add them
up, they should total 0x00000000.
...what?
Thanks!
--- In l..., "rtstofer" wrote: >
> --- In l..., "acetoel" wrote:
> >
> > In the Hex file generated by the compiler (GNUARM) I see this
> >
> >
> > :1000000018F09FE518F09FE518F09FE518F09FE5C0
> > :1000100018F09FE50000A0E1F0FF1FE514F09FE558
> >
> > There is a 0x00 at 0x14, but when I program the MCU, in the memory dump I
see somethings different from 0x14 to 0x17
>
> That's good because your programmer calculated and inserted the checksum
for you.
>
> Now, if you break out the first 8 words and add them up, they should total
0x00000000.
>
> I didn't try that.
>
> Richard
>
Reply by rtstofer●December 30, 20092009-12-30
--- In l..., "acetoel" wrote: >
> In the Hex file generated by the compiler (GNUARM) I see this
> :1000000018F09FE518F09FE518F09FE518F09FE5C0
> :1000100018F09FE50000A0E1F0FF1FE514F09FE558
>
> There is a 0x00 at 0x14, but when I program the MCU, in the memory dump I see
somethings different from 0x14 to 0x17
That's good because your programmer calculated and inserted the checksum
for you.
Now, if you break out the first 8 words and add them up, they should total
0x00000000.
