Lpc2000

I'm looking for routines that enables my lpc2129 to safely read 
a .hex data file through the serial port into temporary RAM. Any 
ideas or code examples?

Although the LPCs operate at high frequencies, I'm a bit concerened 
about just sending hex data just like an ordinary ASCII string 
because of possible problems which can cause data loss...for 
example, reading 1 ASCII value into memory too slowly between uart 
(RDA) interrupts. What's the best way of avoiding this possible 
situation?

thanks in advance,
Leighton

At 08:31 PM 6/21/04 +0000, you wrote:
>I'm looking for routines that enables my lpc2129 to safely read
>a .hex data file through the serial port into temporary RAM. Any
>ideas or code examples?
>
>Although the LPCs operate at high frequencies, I'm a bit concerened
>about just sending hex data just like an ordinary ASCII string
>because of possible problems which can cause data loss...for
>example, reading 1 ASCII value into memory too slowly between uart
>(RDA) interrupts. What's the best way of avoiding this possible
>situation?

First enable the FIFOs.  If you set the threshold about midway that will 
give you extra time to respond and reduce the interrupt overhead.

But if you are really concerned about this you will need some sort of 
handshaking protocol.  Kermit and x-modem are both relatively small.

What are you trying to do?  For a simple terminal like interface I wouldn't 
bother doing more than maybe enabling the FIFO and echoing the typed in 
characters.  If you are loading data or code I'd consider a real download 
program (and ditch the ASCII representation).  If it's something like a 
remote instrument interface I'd enable the FIFO and maybe add a checksum of 
some sort to the end of the command so you can verify it and send back an 
error code.

I wouldn't be surprised if noise was at least as big an issue as response 
latency but that really depends on your application.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Leighton Rowe wrote:

> I'm looking for routines that enables my lpc2129 to safely read
> a .hex data file through the serial port into temporary RAM. Any
> ideas or code examples?
>
> Although the LPCs operate at high frequencies, I'm a bit concerened
> about just sending hex data just like an ordinary ASCII string
> because of possible problems which can cause data loss...for
> example, reading 1 ASCII value into memory too slowly between uart
> (RDA) interrupts. What's the best way of avoiding this possible
> situation?

Are you serious? I can dump .hex files down into an 8-pin PIC (no Uart) 
running at 1Mhz effective rate and load (burn) this information into 
another micro after every line. On any other 8-bit micro with a Uart and 
some Ram I have absolutely no problems keeping up. Why would you think 
that an LPC2129 can't keep up? Is it running at 32KHz? Does it disable 
the interrupts for long periods? Are you pumping the hex file in at 10Mbaud?

Hex files always include a primitive checksum so you can always check 
for integrity. Coms drivers should include some form of handshaking and 
in most instances I prefer to use Xon/Xoff. If there was no way you 
could handshake then I suggest that you just send the hex file a few 
times, your s/w could just reject bad lines and so hopefully and 
statiscally you should finally receive all hex data lines intact. 
Tracking software could even signal whether it is happy or not at the 
end of each file.

Really, the LPC2129 is more than capable of handling such simple tasks, 
with or without a Uart FIFO. There should be no reason that the 2129 
should miss any characters at all and no real reason that your s/w 
should either. If you are in doubt then please inform us of the basis 
for your concerns.


--
Peter Jakacki

Sounds like alot of time to work with. Thanks for the
stats. Well, I'm just working on a component that
takes in some hex code (from a file) and flash
programs a specific sector, somewhat like the philips
flash utility. 

I thought about looking thru the IAP on-chip code but
honestly 8kb's of assembly (7fffe000-80000000) is a
handful to look at.

I've been browsing some arm libraries for IAP source
code routines and found some useful C routines but not
any yet that has the hex file read capability. 


--- Peter Jakacki <peterjak@...> wrote:
> Leighton Rowe wrote:
> 
> > I'm looking for routines that enables my lpc2129
> to safely read
> > a .hex data file through the serial port into
> temporary RAM. Any
> > ideas or code examples?
> >
> > Although the LPCs operate at high frequencies, I'm
> a bit concerened
> > about just sending hex data just like an ordinary
> ASCII string
> > because of possible problems which can cause data
> loss...for
> > example, reading 1 ASCII value into memory too
> slowly between uart
> > (RDA) interrupts. What's the best way of avoiding
> this possible
> > situation?
> 
> Are you serious? I can dump .hex files down into an
> 8-pin PIC (no Uart) 
> running at 1Mhz effective rate and load (burn) this
> information into 
> another micro after every line. On any other 8-bit
> micro with a Uart and 
> some Ram I have absolutely no problems keeping up.
> Why would you think 
> that an LPC2129 can't keep up? Is it running at
> 32KHz? Does it disable 
> the interrupts for long periods? Are you pumping the
> hex file in at 10Mbaud?
> 
> Hex files always include a primitive checksum so you
> can always check 
> for integrity. Coms drivers should include some form
> of handshaking and 
> in most instances I prefer to use Xon/Xoff. If there
> was no way you 
> could handshake then I suggest that you just send
> the hex file a few 
> times, your s/w could just reject bad lines and so
> hopefully and 
> statiscally you should finally receive all hex data
> lines intact. 
> Tracking software could even signal whether it is
> happy or not at the 
> end of each file.
> 
> Really, the LPC2129 is more than capable of handling
> such simple tasks, 
> with or without a Uart FIFO. There should be no
> reason that the 2129 
> should miss any characters at all and no real reason
> that your s/w 
> should either. If you are in doubt then please
> inform us of the basis 
> for your concerns.
> 
> 
> --
> Peter Jakacki
> 
> 
> 
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

> I'm looking for routines that enables my lpc2129 to safely read a
> .hex data file through the serial port into temporary RAM. Any
> ideas or code examples?
 
> Although the LPCs operate at high frequencies, I'm a bit
> concerened about just sending hex data just like an ordinary
> ASCII string because of possible problems which can cause data
> loss...for example, reading 1 ASCII value into memory too slowly
> between uart (RDA) interrupts.

What are you going to do with the HEX data? If you are going to 
turn it back into binary, just reduce to binary before sending. 
If you send it with (say) 128-byte Xmodem, overrun can be 
prevented by using a 131 byte serial buffer and enabling the 
FIFOs to reduce interrupt overhead. We run our USB Stamps this 
way and have no problems - I *never* see the retry counter go 
up. We process the incoming data before sending the block 
acknowledgement, so flow control is automatic. This is done on 
an LPC2106 at 60MHz with MAM fully enabled. The 2129 should be 
the same.

Stephen

--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

sorry for the delay...thanks Steve,

After some trials, I'm totally convinced the lpc2129 won't overun 
the UART buffer (with or without using the Xmodem u mentioned)...as 
long as I code it correctly. Currently I plan to use the HEX data by 
loading an empty block of flash with the data & attempt to execute 
it like normal code.

Now here's a tricky situation:
You're uploading code from the Host(PC) thru UART to flash-program 
the target system(LPC)
- The code (data) could be any size within 8k.
- IAP flash bootloader is configured to program only 512 bytes at a 
time (smallest available chunk)
- Given the PC/Target communication protocol, command & data packets 
can be transmitted. But data packets are limited to only 150 bytes 
(maximum) per packet...had it been >=512 bytes I probably wouldn't 
write this question. 

I know the IAP & UART routines to use but this is new stuff that I 
haven't tried before. Any Advice? Thanks.

Leighton


 

--- In lpc2000@yahoogroups.com, "Stephen Pelc" <stephen@m...> wrote:

> > I'm looking for routines that enables my lpc2129 to safely read a
> > .hex data file through the serial port into temporary RAM. Any
> > ideas or code examples?
>  
> > Although the LPCs operate at high frequencies, I'm a bit
> > concerened about just sending hex data just like an ordinary
> > ASCII string because of possible problems which can cause data
> > loss...for example, reading 1 ASCII value into memory too slowly
> > between uart (RDA) interrupts.
> 
> What are you going to do with the HEX data? If you are going to 
> turn it back into binary, just reduce to binary before sending. 
> If you send it with (say) 128-byte Xmodem, overrun can be 
> prevented by using a 131 byte serial buffer and enabling the 
> FIFOs to reduce interrupt overhead. We run our USB Stamps this 
> way and have no problems - I *never* see the retry counter go 
> up. We process the incoming data before sending the block 
> acknowledgement, so flow control is automatic. This is done on 
> an LPC2106 at 60MHz with MAM fully enabled. The 2129 should be 
> the same.
> 
> Stephen
> 
> --
> Stephen Pelc, stephen@m...
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 23 80 631441, fax: +44 23 80 339691
> web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

> After some trials, I'm totally convinced the lpc2129 won't overun
> the UART buffer (with or without using the Xmodem u
> mentioned)...as long as I code it correctly. Currently I plan to
> use the HEX data by loading an empty block of flash with the data
> & attempt to execute it like normal code.
Our Xmodem system works fine on a 2129 - the hardware/software 
combination should be available in a few weeks from MPE and New 
Micros. The software will be an extension of that for the 
TiniARM.

> Now here's a tricky situation:
> You're uploading code from the Host(PC) thru UART to
> flash-program the target system(LPC) - The code (data) could be
> any size within 8k. - IAP flash bootloader is configured to
> program only 512 bytes at a time (smallest available chunk) -
> Given the PC/Target communication protocol, command & data
> packets can be transmitted. But data packets are limited to only
> 150 bytes (maximum) per packet...had it been >=512 bytes I
> probably wouldn't write this question.
Why is this tricky? Buffer four 128 byte blocks to get a 512 
byte block. The only times you fail totally is if you do not 
implement retries on a block error or the link fails 
permanently. The ISP loader is then your saviour. If you can 
afford to buffer all 8kb, then you have an extra level of 
safety. The code we load into RAM to do this is about 3kb, uses 
a few hundred bytes of RAM for stacks and so on, so even the 
smallest LPC has 12k of RAM for buffering.

If you have a lot of RAM data you need to preserve, why not put 
in spare Flash, perform the load, and restore the RAM?

As a caution, I suspect but have no proof that most Flash write 
failures are down to poor power supplies.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

> Why is this tricky? Buffer four 128 byte blocks to get a 512 
> byte block. The only times you fail totally is if you do not 
> implement retries on a block error or the link fails 
> permanently. The ISP loader is then your saviour. If you can 
> afford to buffer all 8kb, then you have an extra level of 
> safety. The code we load into RAM to do this is about 3kb, uses 
> a few hundred bytes of RAM for stacks and so on, so even the 
> smallest LPC has 12k of RAM for buffering.
> 
> If you have a lot of RAM data you need to preserve, why not put 
> in spare Flash, perform the load, and restore the RAM?
> 
> As a caution, I suspect but have no proof that most Flash write 
> failures are down to poor power supplies.
> 

Fair enough...using multiple blocks is worth trying out then. With 
16k RAM buffering wouldn't be a problem at all. The ISP on my system 
is available only for the 1st load because of the hardware setup I 
got enclosed case & P0.14 as an LED driver). I'll have to get around 
ISPs with IAP routines for future downloads.

Thanks for the caution. 
Leighton

Leighton Rowe wrote:
> Fair enough...using multiple blocks is worth trying out then. With 
> 16k RAM buffering wouldn't be a problem at all. The ISP on my system 
> is available only for the 1st load because of the hardware setup I 
> got enclosed case & P0.14 as an LED driver). I'll have to get around 
> ISPs with IAP routines for future downloads.

Just a quick untested idea: I wonder if instead of implementing your own 
bootloader because P0.14 is physically inaccessible, you could force it 
to enter the built in bootloader on the next reboot by corrupting the 
vector table checksum word? Of course it will then be completely 
unbootable until the flash is reprogrammed so you want to be careful 
that you only do it when you're sure the user wants to reprogram the device.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

> Just a quick untested idea: I wonder if instead of implementing 
your own 
> bootloader because P0.14 is physically inaccessible, you could 
force it 
> to enter the built in bootloader on the next reboot by corrupting 
the 
> vector table checksum word? Of course it will then be completely 
> unbootable until the flash is reprogrammed so you want to be 
careful 
> that you only do it when you're sure the user wants to reprogram 
the device.

That'll be risky business indeed. Luckily, the built-in IAP flash 
programmer can program anywhere except the bootloader sector. I think 
if you corrupt reset table the mcu will be totally useless on 
reset...not even the bootloader will run. 

I'm attempting to implement something similar to your idea but 
instead of rewriting vector tables/chksum every time, use a 
modifiable patch table containing addresses to the various 
functions...as someone mentioned a few weeks ago.

Flash Updating is a fun trick for new ppl like me to master but hey. 
Flash-write routines, and C/assembly code are the only tools I needed.

At 09:57 PM 7/5/04 +0000, you wrote:
> > Just a quick untested idea: I wonder if instead of implementing
>your own
> > bootloader because P0.14 is physically inaccessible, you could
>force it
> > to enter the built in bootloader on the next reboot by corrupting
>the
> > vector table checksum word? Of course it will then be completely
> > unbootable until the flash is reprogrammed so you want to be
>careful
> > that you only do it when you're sure the user wants to reprogram
>the device.
>
>That'll be risky business indeed. Luckily, the built-in IAP flash
>programmer can program anywhere except the bootloader sector. I think
>if you corrupt reset table the mcu will be totally useless on
>reset...not even the bootloader will run.

I don't believe the OP is talking about rewriting the bootload sector just 
the interrupt vector table (which is at the beginning of the flash rather 
than the end).  If I were trying that I'd just erase the first sector 
(sector/segment/paragraph whatever they call it). That should be relatively 
safe.  The chip would then act as if it were new.  Whether that's better 
than bringing out P0.14 for toggling is a different question.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Robert Adsett wrote:
> At 09:57 PM 7/5/04 +0000, you wrote:
>>That'll be risky business indeed. Luckily, the built-in IAP flash
>>programmer can program anywhere except the bootloader sector. I think
>>if you corrupt reset table the mcu will be totally useless on
>>reset...not even the bootloader will run.
> I don't believe the OP is talking about rewriting the bootload sector just 
> the interrupt vector table (which is at the beginning of the flash rather 
> than the end).  If I were trying that I'd just erase the first sector 
> (sector/segment/paragraph whatever they call it). That should be relatively 
> safe.  The chip would then act as if it were new.  Whether that's better 
> than bringing out P0.14 for toggling is a different question.

Exactly. If the vector table at the beginning of user flash doesn't 
checksum correctly, the chip goes into bootloader mode after reset and 
you can reprogram it over the serial port even if P0.14 is permanently 
tied high. As you say erasing the first sector is probably the easiest 
way of corrupting the vector table.

BTW on a (sort of) related note, the current version of lpc21isp doesn't 
work on big endian systems like Macs because it calculates the vector 
block checksum incorrectly causing the device to always enter the 
bootloader on reset. I wrote a patch which fixes this and sent it to the 
author but haven't got any response. There's a copy here:
http://www.alexholden.net/misc/lpc21isp-byte_safety.patch

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

> Exactly. If the vector table at the beginning of user flash 
doesn't 
> checksum correctly, the chip goes into bootloader mode after reset 
and 
> you can reprogram it over the serial port even if P0.14 is 
permanently 
> tied high. As you say erasing the first sector is probably the 
easiest 
> way of corrupting the vector table.
> 
> BTW on a (sort of) related note, the current version of lpc21isp 
doesn't 
> work on big endian systems like Macs because it calculates the 
vector 
> block checksum incorrectly causing the device to always enter the 
> bootloader on reset. I wrote a patch which fixes this and sent it 
to the 
> author but haven't got any response. There's a copy here:
> http://www.alexholden.net/misc/lpc21isp-byte_safety.patch
> 


I kinda misinterpreted the chksum check process (at reboot) and 
erasing the 1st sector but the last 2 comments by Alex & Robert 
cleared that up bigtime. Thanks. There's more than a way to do ISPs 
afterall :). Thanks for the patch Alex. It's very helpful stuff. I 
had a very hard time finding ISP-related source code to play with 
until now. Trying out lpc21isp might make my day.  





Onwards

When have you sent it ? To which email address ?
I think i haven't received an email about this topic...

Regards,

        Martin

PS: I will merge this change in and release it to my website.

----- Original Message ----- 
From: "Alex Holden" <alex@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, July 06, 2004 9:06 AM
Subject: Re: [lpc2000] Re: loading hex-es....(Tricky Situation)


> Robert Adsett wrote:
> > At 09:57 PM 7/5/04 +0000, you wrote:
> >>That'll be risky business indeed. Luckily, the built-in IAP flash
> >>programmer can program anywhere except the bootloader sector. I think
> >>if you corrupt reset table the mcu will be totally useless on
> >>reset...not even the bootloader will run.
> > I don't believe the OP is talking about rewriting the bootload sector
just
> > the interrupt vector table (which is at the beginning of the flash
rather
> > than the end).  If I were trying that I'd just erase the first sector
> > (sector/segment/paragraph whatever they call it). That should be
relatively

> > safe.  The chip would then act as if it were new.  Whether that's better
> > than bringing out P0.14 for toggling is a different question.
>
> Exactly. If the vector table at the beginning of user flash doesn't
> checksum correctly, the chip goes into bootloader mode after reset and
> you can reprogram it over the serial port even if P0.14 is permanently
> tied high. As you say erasing the first sector is probably the easiest
> way of corrupting the vector table.
>
> BTW on a (sort of) related note, the current version of lpc21isp doesn't
> work on big endian systems like Macs because it calculates the vector
> block checksum incorrectly causing the device to always enter the
> bootloader on reset. I wrote a patch which fixes this and sent it to the
> author but haven't got any response. There's a copy here:
> http://www.alexholden.net/misc/lpc21isp-byte_safety.patch
>
> -- 
> ------------ Alex Holden - http://www.linuxhacker.org ------------
> If it doesn't work, you're not hitting it with a big enough hammer
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>