ISP for the LPC935
Started by ●March 28, 2005
All,
I have just written and am using some code to program an LPC935.
Would any vody else be interested it works on Linux and Windows
compiles with Mingw on Windows and GCC under Linux.
If so I tar it up and post it here?
I would be interested in comments and bug fixes if anybody else starts
using it.
Rod
Reply by ●March 28, 20052005-03-28
Hi Rod,
> I have just written and am using some code to program an LPC935.
> Would any vody else be interested it works on Linux and Windows
> compiles with Mingw on Windows and GCC under Linux.
>
> If so I tar it up and post it here?
>
> I would be interested in comments and bug fixes if anybody else starts
> using it.
What bootloader entry method do you use? Hardware activation (3x pulse on
RST)?
I would like to use it with a LPC932 though, so a few changes will probably
be needed to get it working (different vector addresses for example).
In any event I would be interested to take a peek at your code.
Sincerely,
Eric
> I have just written and am using some code to program an LPC935.
> Would any vody else be interested it works on Linux and Windows
> compiles with Mingw on Windows and GCC under Linux.
>
> If so I tar it up and post it here?
>
> I would be interested in comments and bug fixes if anybody else starts
> using it.
What bootloader entry method do you use? Hardware activation (3x pulse on
RST)?
I would like to use it with a LPC932 though, so a few changes will probably
be needed to get it working (different vector addresses for example).
In any event I would be interested to take a peek at your code.
Sincerely,
Eric
Reply by ●March 28, 20052005-03-28
It is very generic there are no limitiation with regards to the boot
vector address or anything. I use the 3-pulses on reset to trigger
entry into the boot vector.
I have also discovered that I am using the DTR and RTS lines in the
opersite way to the flash magic code but I am still using DTR for
power and RTS for reset. Using this method ment that I only needs a
single transistor to do the level shifting for both those signals. I
have my programming PCB soldered in the back of a DB9 backshell. I'm
thinking by addind a switch to the outside of it I could enable it for
programming and then for data cpature and well but that is for another
revision.
I'm also not sure about code licensing I'm thinking about the GNU
license for the programming code what does everybody else think?
Regards,
Rod Boyce.
--- In lpc900_users@lpc9..., Eric Rullens <gorilla@d...> wrote:
> Hi Rod,
>
> > I have just written and am using some code to program an LPC935.
> > Would any vody else be interested it works on Linux and Windows
> > compiles with Mingw on Windows and GCC under Linux.
> >
> > If so I tar it up and post it here?
> >
> > I would be interested in comments and bug fixes if anybody else starts
> > using it.
>
> What bootloader entry method do you use? Hardware activation (3x
pulse on
> RST)?
>
> I would like to use it with a LPC932 though, so a few changes will
probably
> be needed to get it working (different vector addresses for example).
>
> In any event I would be interested to take a peek at your code.
>
> Sincerely,
>
> Eric
Reply by ●March 28, 20052005-03-28
rodboyce70 wrote:
>
> All,
>
> I have just written and am using some code to program an LPC935.
> Would any vody else be interested it works on Linux and Windows
> compiles with Mingw on Windows and GCC under Linux.
>
> If so I tar it up and post it here?
>
> I would be interested in comments and bug fixes if anybody else starts
> using it.
>
I would find it very usefull as I am very interested in Linux tools
for 8051 development. Have a look at my page at 8052.com which is:
http://www.8052.com/users/redtommo
Ian
--
Ian T-Bell
aka RuffRecords
aka RedTommo
>
> All,
>
> I have just written and am using some code to program an LPC935.
> Would any vody else be interested it works on Linux and Windows
> compiles with Mingw on Windows and GCC under Linux.
>
> If so I tar it up and post it here?
>
> I would be interested in comments and bug fixes if anybody else starts
> using it.
>
I would find it very usefull as I am very interested in Linux tools
for 8051 development. Have a look at my page at 8052.com which is:
http://www.8052.com/users/redtommo
Ian
--
Ian T-Bell
aka RuffRecords
aka RedTommo
Reply by ●March 28, 20052005-03-28
rodboyce70 wrote:
>
> I'm also not sure about code licensing I'm thinking about the GNU
> license for the programming code what does everybody else think?
>
Unless you think you can make a lot of money out of it then I would
recommend the GNU licence. At least that way others can extend it but
it remains free.
Ian
--
Ian T-Bell
aka RuffRecords
aka RedTommo
>
> I'm also not sure about code licensing I'm thinking about the GNU
> license for the programming code what does everybody else think?
>
Unless you think you can make a lot of money out of it then I would
recommend the GNU licence. At least that way others can extend it but
it remains free.
Ian
--
Ian T-Bell
aka RuffRecords
aka RedTommo
Reply by ●March 28, 20052005-03-28
All,
There you go it is still a work in progress and I have placed it under
the LGPL. Have a look and see what you think if anybody else likes it
I may even consider creating a project on Source Forge for it.
Regards,
Rod Boyce
--- In lpc900_users@lpc9..., "rodboyce70" <rodboyce70@y...> wrote:
>
> All,
>
> I have just written and am using some code to program an LPC935.
> Would any vody else be interested it works on Linux and Windows
> compiles with Mingw on Windows and GCC under Linux.
>
> If so I tar it up and post it here?
>
> I would be interested in comments and bug fixes if anybody else starts
> using it.
>
> Rod
Reply by ●March 29, 20052005-03-29
Hi Rod,
Sure looks good, I'll have better look at it when time permits.
Of course you will be the first one to know when I have any comments or
fixes.
Maybe a first question: have you looked at the reset pulses with a scope or
something? Because I can hardly believe that
udelay( 48 );
udelay( 16 );
will actually give a reliable delay of the specified time. This may not be a
problem, because the periods are minimum times, but I was just wondering.
;-)
(When debugging the Software Academy solotion I found that they use the UART
itself to generate quite consistent pulses by switching to a much higher
baudrate and then sending 0xff.)
Thanks,
Eric
> All,
>
> There you go it is still a work in progress and I have placed it under
> the LGPL. Have a look and see what you think if anybody else likes it
> I may even consider creating a project on Source Forge for it.
>
> Regards,
> Rod Boyce
>
> --- In lpc900_users@lpc9..., "rodboyce70"
> <rodboyce70@y...> wrote:
> >
> > All,
> >
> > I have just written and am using some code to program an LPC935.
> > Would any vody else be interested it works on Linux and Windows
> > compiles with Mingw on Windows and GCC under Linux.
> >
> > If so I tar it up and post it here?
> >
> > I would be interested in comments and bug fixes if anybody
> else starts
> > using it.
> >
> > Rod
Sure looks good, I'll have better look at it when time permits.
Of course you will be the first one to know when I have any comments or
fixes.
Maybe a first question: have you looked at the reset pulses with a scope or
something? Because I can hardly believe that
udelay( 48 );
udelay( 16 );
will actually give a reliable delay of the specified time. This may not be a
problem, because the periods are minimum times, but I was just wondering.
;-)
(When debugging the Software Academy solotion I found that they use the UART
itself to generate quite consistent pulses by switching to a much higher
baudrate and then sending 0xff.)
Thanks,
Eric
> All,
>
> There you go it is still a work in progress and I have placed it under
> the LGPL. Have a look and see what you think if anybody else likes it
> I may even consider creating a project on Source Forge for it.
>
> Regards,
> Rod Boyce
>
> --- In lpc900_users@lpc9..., "rodboyce70"
> <rodboyce70@y...> wrote:
> >
> > All,
> >
> > I have just written and am using some code to program an LPC935.
> > Would any vody else be interested it works on Linux and Windows
> > compiles with Mingw on Windows and GCC under Linux.
> >
> > If so I tar it up and post it here?
> >
> > I would be interested in comments and bug fixes if anybody
> else starts
> > using it.
> >
> > Rod
Reply by ●March 29, 20052005-03-29
I do not task switch when I create these pulses and I have checked
them on a scope and they are well within the spec. If you look a bit
further down in the code you will find my udelay function for both
windows and Linux in both cases I do these manualy without calling on
the OS to time slice me. I had to done a lot of research to figure
out the windows one I stumbled on the answer while looking at some
other open source code it pointed me at the two OS calls to perform a
very precise timmimg measurements once I discovered this I was able to
do a very precise timming delay. Anyway I have been playig with it
some more and I have speed up the programming function from what you
see here. Now I'm thinking I will create a source forge project for
this as now I have two versions out there. So stay tuned....
Regards,
Rod Boyce.
--- In lpc900_users@lpc9..., Eric Rullens <gorilla@d...> wrote:
> Hi Rod,
>
> Sure looks good, I'll have better look at it when time permits.
>
> Of course you will be the first one to know when I have any comments or
> fixes.
>
> Maybe a first question: have you looked at the reset pulses with a
scope or
> something? Because I can hardly believe that
>
> udelay( 48 );
> udelay( 16 );
>
> will actually give a reliable delay of the specified time. This may
not be a
> problem, because the periods are minimum times, but I was just
wondering.
> ;-)
>
> (When debugging the Software Academy solotion I found that they use
the UART
> itself to generate quite consistent pulses by switching to a much higher
> baudrate and then sending 0xff.)
>
> Thanks,
> Eric
>
> > All,
> >
> > There you go it is still a work in progress and I have placed it under
> > the LGPL. Have a look and see what you think if anybody else likes it
> > I may even consider creating a project on Source Forge for it.
> >
> > Regards,
> > Rod Boyce
> >
> > --- In lpc900_users@lpc9..., "rodboyce70"
> > <rodboyce70@y...> wrote:
> > >
> > > All,
> > >
> > > I have just written and am using some code to program an LPC935.
> > > Would any vody else be interested it works on Linux and Windows
> > > compiles with Mingw on Windows and GCC under Linux.
> > >
> > > If so I tar it up and post it here?
> > >
> > > I would be interested in comments and bug fixes if anybody
> > else starts
> > > using it.
> > >
> > > Rod
Reply by ●March 29, 20052005-03-29
Hi Rod,
> I do not task switch when I create these pulses and I have checked
I know, but the OS may very well decide to switch when the code in the
timing loop... In that case you'll see delays from several ms to hundreds of
ms.
> them on a scope and they are well within the spec. If you look a bit
> further down in the code you will find my udelay function for both
> windows and Linux in both cases I do these manualy without calling on
> the OS to time slice me. I had to done a lot of research to figure
> out the windows one I stumbled on the answer while looking at some
> other open source code it pointed me at the two OS calls to perform a
> very precise timmimg measurements once I discovered this I was able to
> do a very precise timming delay. Anyway I have been playig with it
I know these functions, the do give you an accurate measurement of time, but
there's absolutely no guarantee about the interval itself when making timing
loops with them. As an additional con, the process will consume 100% cpu
power when in the loop waiting for the time to pass by. I've seen
programming 'horrors' grinding a 3 GHz P4 to a halt with 1200 BPS
communications using this timing principle... Of course the impact isn't
that great in this case, since only 3 pulses are needed.
But letting the UART do the hard work isn't a bad idea at all (when
possible).
> some more and I have speed up the programming function from what you
> see here. Now I'm thinking I will create a source forge project for
> this as now I have two versions out there. So stay tuned....
I really appreciate your effort, keep up the good work. :-)
Eric > --- In lpc900_users@lpc9..., Eric Rullens
> <gorilla@d...> wrote:
> > Hi Rod,
> >
> > Sure looks good, I'll have better look at it when time permits.
> >
> > Of course you will be the first one to know when I have any
> comments or
> > fixes.
> >
> > Maybe a first question: have you looked at the reset pulses with a
> scope or
> > something? Because I can hardly believe that
> >
> > udelay( 48 );
> > udelay( 16 );
> >
> > will actually give a reliable delay of the specified time. This may
> not be a
> > problem, because the periods are minimum times, but I was just
> wondering.
> > ;-)
> >
> > (When debugging the Software Academy solotion I found that they use
> the UART
> > itself to generate quite consistent pulses by switching to
> a much higher
> > baudrate and then sending 0xff.)
> >
> > Thanks,
> > Eric
> >
> > > All,
> > >
> > > There you go it is still a work in progress and I have
> placed it under
> > > the LGPL. Have a look and see what you think if anybody
> else likes it
> > > I may even consider creating a project on Source Forge for it.
> > >
> > > Regards,
> > > Rod Boyce
> > >
> > > --- In lpc900_users@lpc9..., "rodboyce70"
> > > <rodboyce70@y...> wrote:
> > > >
> > > > All,
> > > >
> > > > I have just written and am using some code to program
> an LPC935.
> > > > Would any vody else be interested it works on Linux and Windows
> > > > compiles with Mingw on Windows and GCC under Linux.
> > > >
> > > > If so I tar it up and post it here?
> > > >
> > > > I would be interested in comments and bug fixes if anybody
> > > else starts
> > > > using it.
> > > >
> > > > Rod
> I do not task switch when I create these pulses and I have checked
I know, but the OS may very well decide to switch when the code in the
timing loop... In that case you'll see delays from several ms to hundreds of
ms.
> them on a scope and they are well within the spec. If you look a bit
> further down in the code you will find my udelay function for both
> windows and Linux in both cases I do these manualy without calling on
> the OS to time slice me. I had to done a lot of research to figure
> out the windows one I stumbled on the answer while looking at some
> other open source code it pointed me at the two OS calls to perform a
> very precise timmimg measurements once I discovered this I was able to
> do a very precise timming delay. Anyway I have been playig with it
I know these functions, the do give you an accurate measurement of time, but
there's absolutely no guarantee about the interval itself when making timing
loops with them. As an additional con, the process will consume 100% cpu
power when in the loop waiting for the time to pass by. I've seen
programming 'horrors' grinding a 3 GHz P4 to a halt with 1200 BPS
communications using this timing principle... Of course the impact isn't
that great in this case, since only 3 pulses are needed.
But letting the UART do the hard work isn't a bad idea at all (when
possible).
> some more and I have speed up the programming function from what you
> see here. Now I'm thinking I will create a source forge project for
> this as now I have two versions out there. So stay tuned....
I really appreciate your effort, keep up the good work. :-)
Eric > --- In lpc900_users@lpc9..., Eric Rullens
> <gorilla@d...> wrote:
> > Hi Rod,
> >
> > Sure looks good, I'll have better look at it when time permits.
> >
> > Of course you will be the first one to know when I have any
> comments or
> > fixes.
> >
> > Maybe a first question: have you looked at the reset pulses with a
> scope or
> > something? Because I can hardly believe that
> >
> > udelay( 48 );
> > udelay( 16 );
> >
> > will actually give a reliable delay of the specified time. This may
> not be a
> > problem, because the periods are minimum times, but I was just
> wondering.
> > ;-)
> >
> > (When debugging the Software Academy solotion I found that they use
> the UART
> > itself to generate quite consistent pulses by switching to
> a much higher
> > baudrate and then sending 0xff.)
> >
> > Thanks,
> > Eric
> >
> > > All,
> > >
> > > There you go it is still a work in progress and I have
> placed it under
> > > the LGPL. Have a look and see what you think if anybody
> else likes it
> > > I may even consider creating a project on Source Forge for it.
> > >
> > > Regards,
> > > Rod Boyce
> > >
> > > --- In lpc900_users@lpc9..., "rodboyce70"
> > > <rodboyce70@y...> wrote:
> > > >
> > > > All,
> > > >
> > > > I have just written and am using some code to program
> an LPC935.
> > > > Would any vody else be interested it works on Linux and Windows
> > > > compiles with Mingw on Windows and GCC under Linux.
> > > >
> > > > If so I tar it up and post it here?
> > > >
> > > > I would be interested in comments and bug fixes if anybody
> > > else starts
> > > > using it.
> > > >
> > > > Rod
Reply by ●March 29, 20052005-03-29
All,
This feedback is very good and explains why when I looked at other
programming designs for the LPC micros the programming interface
seemed that the the reset line was gated with the RxD and RTS. I saw
no purpose for this and ignored it.
I have calculated the time spent doing these three pulses and it comes
to 192uS in fact when I tried slower loops and alterations in my
udelay function I was not able to make it work.
The time taken to perform these pulses is very small and the likely
hood of a task switch at that time is small but I have seen on a scope
one of my hi going pulses stretched to as much as 50uS under windows
and it did not effect the entry into bootstrap mode I was surprised at
this. I have only measured the pulses from a windows PC but I use
this programmer from Linux at home. I only have access to a scope at
work in my lunch time so I measured them there. Out of 12 odd
measurements only once did I see the pulse timing change. I know this
is not a very big sample but it is a home project and that is more
than enough for me.
I was thinking that I could force a task switch before starting the
pulses this would put me at the beginning of the time slice and make
switching away mid sequence even more unlikely. I do agree about CPU
usage it will spike under this kind of loading but it is for such a
short time that I am happy to do this when needed.
When I measured these pulses on my windows PC I also had the task
manager open it did not notice my short spikes I will recheck when I
get time.
I could also see another way to send the pulses when gating Rxd and
RTS together. You could slow the baud rate down and use a single byte
to transmit the pulses something like 8 data bits and no parity would
provide enough data bits to send S12345678 100100100 with a slow baud
rate but my simple design does not do this. This would not require
multipule data bytes as I have seen gaps of up to 20mS between bytes.
Anyway that is the beauty of open source if you don't like something
you can change it. This is also the beauty of free tools you can pick
what you want to use. All these comments are very valuable to me
thank you very much do feel free to check out this tool if you like it
and let me know how you go I will put up a new version in the next
couple of days. I have to modify and test the windows version with my
changes so far.
I have noticed that my mechanism does not work over a USB serial cable
and using the RTS / Rxd gated aproach may work on a USB serial cable.
But with the current project I have pleanty of PCs with serial ports
on them to develop from so I'm not bothered yet.
Regards,
Rod Boyce --- In lpc900_users@lpc9..., Eric Rullens <gorilla@d...>
wrote:
> Hi Rod,
>
> > I do not task switch when I create these pulses and I have checked
>
> I know, but the OS may very well decide to switch when the code in
the
> timing loop... In that case you'll see delays from several ms to
hundreds of
> ms.
>
> > them on a scope and they are well within the spec. If you look a
bit
> > further down in the code you will find my udelay function for both
> > windows and Linux in both cases I do these manualy without
calling on
> > the OS to time slice me. I had to done a lot of research to
figure
> > out the windows one I stumbled on the answer while looking at some
> > other open source code it pointed me at the two OS calls to
perform a
> > very precise timmimg measurements once I discovered this I was
able to
> > do a very precise timming delay. Anyway I have been playig with
it
>
> I know these functions, the do give you an accurate measurement of
time, but
> there's absolutely no guarantee about the interval itself when
making timing
> loops with them. As an additional con, the process will consume
100% cpu
> power when in the loop waiting for the time to pass by. I've seen
> programming 'horrors' grinding a 3 GHz P4 to a halt with 1200 BPS
> communications using this timing principle... Of course the impact
isn't
> that great in this case, since only 3 pulses are needed.
>
> But letting the UART do the hard work isn't a bad idea at all (when
> possible).
>
> > some more and I have speed up the programming function from what
you
> > see here. Now I'm thinking I will create a source forge project
for
> > this as now I have two versions out there. So stay tuned....
>
> I really appreciate your effort, keep up the good work. :-)
>
> Eric
