Searching \ for '[PIC] reply to Byron A. Jeff re: Bootloader prob' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'reply to Byron A. Jeff re: Bootloader prob'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] reply to Byron A. Jeff re: Bootloader prob'
2004\12\09@085227 by J. Gromlich

flavicon
face
Hi Byron:

I basically agree with most of your post, although I don't do MIDI
so I don't have your need for a separate programming input to the
chip.  I'm going to snip out a lot of the previous messages so as to
not tie up bandwidth.

=====================  ORIGINAL MESSAGE ====================

On Mon, Dec 06, 2004 at 09:13:48AM -0500, Roy J. Gromlich wrote:
> Hi Jan-Erik:

>>> Roy,

>>> I'm going to horn in because it's a bootloader discussion.

You are welcome to jump in any time - this is a free place for everyone.

>>>  using or developing Open Source tools.

I had not found any Open Source PIC programming tools,
but then I probably don't know where to look.

>>>  they only have multiword writes (4 or 8 words) to write.
>>> The second issue is that newer PICS requires a row erase,
>>> generally 32 words, before you can write to it. With Tiny,
>>> such a row erase could be added silently.

Tiny already erases and programs the Flash Program memory just
fine, so it already knows how to do multi-word erase and write.
The problem is that it can't write to the Configuration registers
- just returns Error! with no explanation.  I am certain TINY could be fixed fairly easily, but the programming algorithm is in the Windows App, and I don't have the source for that part.

>>> A better idea may be to use Tato's PLoader.
>>> You can find the project here: http://propic2.com/ploader

I will check it out as soon as I get some free time - probably
over this coming weekend.

>>> Finally someone that appreciates the power of the bootloader...

Coming from the world of erase the EPROM / burn the EPROM, I really appreciated the first uProc development system I had which
allowed loading the code  into emulation RAM.. What a time saving
that was, even though the code went away when power went off.

>>> But a good command protocol should mask most of the issues.
If (that's a BIG if) you can anticipate the possible changes in new
chips programming requirements, you can have a parameter file for
the programmer which has entries for each new chip, telling the
programmer how to do it.
>>> I strongly feel that the hardware USART should be available to
>>> the application instead of having to share with the bootloader.

I understand, and even agree to an extent.  As I said, the UART is
already connected to the computer doing the programming, so having
the programmer and the application take turns using the RS232 isn't
a serious problem.

>>> Everyone else requires that you move at least to address 4 or 8.

I almost always write code so the first 2 bytes are a jump to the
system initialization code, so that isn't an issue.

>>> Only 18F parts can do that. You should read Wouter's
>>> explanation to why messing with config regs is a bad idea
>>> even for 18F parts. In short it allows the bootloader to
>>> potentially disable itself, which is a no no.

I would agree that would be a nasty problem, but the firmware
you are testing could always find strange ways to disable the device being tested.

>>>BAJ

I am trying to get in touch with the author of TinyBootloader to
see if I can get the source for the Windows app which does the
programming.  Unfortunately, it appears to have been written
in Delphi, and I don't have a development system for that suite.

Roy


___________________________________________

2004\12\09@091255 by Peter Moreton

flavicon
face
>I am trying to get in touch with the author of TinyBootloader to see if I
can get the source for the Windows >app which does the programming.
Unfortunately, it appears to have been written in Delphi, and I don't have
>a development system for that suite.

You can download a free demo version of delphi, which expires in 30 days or
so. Should be enough time, if you have some working source to begin with!

____________________________________________

2004\12\09@103329 by olin_piclist

face picon face
Roy J. Gromlich wrote:
>>>>  using or developing Open Source tools.
>
> I had not found any Open Source PIC programming tools,
> but then I probably don't know where to look.

The schematics, BOM, firmware, and host software are all available for my
EasyProg PIC programmer.  Start at http://www.embedinc.com/easyprog.  While
the host software and its build environment are available, documentation for
the build environment is still missing.  However, if someone is serious
about messing with it, I'll try to get to that sooner rather than later.

> If (that's a BIG if) you can anticipate the possible changes in new
> chips programming requirements, you can have a parameter file for
> the programmer which has entries for each new chip, telling the
> programmer how to do it.

I thought about that and decided it would be too difficult to come up with a
sufficiently flexible description that would work for all the different
programming algorithms, and then the ones yet to be defined.  In the end I
decided on a driver architecture.  Specific drivers for reset, read, and
write are installed for the chip type being programmed.  These present a
common interface to the rest of the system which doesn't have to know about
the low level programming interface to each chip.

I did put other target chip parameters into a configuration file.  These
include things like what the device ID word is, how much program memory the
chip has, where the config words are, which bits in them are implemented,
etc.  This file is ENV/PICPRG.ENV after you install my PIC programmer
software.

To add a new chip that uses existing algorithms, an entry only needs to be
added to PICPRG.ENV.  To support a new programming algorithms, the low level
drivers need to be written, IDs and names added to the software for these
new drivers, and a section added to PICPRG.ENV that includes reference to
the new algorithms.

After adding support for a number of new algorithms, this still seems like a
good model.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\12\09@110105 by Alan B. Pearce

face picon face
>The problem is that it can't write to the
>Configuration registers - just returns Error!
>with no explanation.  I am certain TINY could
>be fixed fairly easily, but the programming
>algorithm is in the Windows App, and I don't
>have the source for that part.

You may be able to fix Tiny, but AFAIK all the 16F parts require HVP mode to
program the config register, and I believe the same may be true for some,
possibly all 18F parts. dsPic 30F parts I cannot recall ever hearing what
happens here.

Because HVP mode is required, you cannot use a bootloader to change the
config register, on those parts where this mode is required.

____________________________________________

2004\12\09@161911 by Vitaliy Maksimov

flavicon
face
> >I am trying to get in touch with the author of TinyBootloader to see if I
> can get the source for the Windows >app which does the programming.
> Unfortunately, it appears to have been written in Delphi, and I don't have
>>a development system for that suite.
>
> You can download a free demo version of delphi, which expires in 30 days
> or
> so. Should be enough time, if you have some working source to begin with!

Or you can download a Personal version, which doesn't expire (I think this
link is to D6):

ftp://ftp.rz.uni-kiel.de/pub/zoo-oek/BorlandDelphiPersonalEdition.exe

Registration is free:

http://www.borland.com/products/downloads/download_delphi.html

Best regards,

Vitaliy

____________________________________________

2004\12\09@195057 by Byron A Jeff

face picon face
On Thu, Dec 09, 2004 at 04:00:59PM -0000, Alan B. Pearce wrote:
> >The problem is that it can't write to the
> >Configuration registers - just returns Error!
> >with no explanation.  I am certain TINY could
> >be fixed fairly easily, but the programming
> >algorithm is in the Windows App, and I don't
> >have the source for that part.
>
> You may be able to fix Tiny, but AFAIK all the 16F parts require HVP mode to
> program the config register, and I believe the same may be true for some,
> possibly all 18F parts. dsPic 30F parts I cannot recall ever hearing what
> happens here.

Here's the scoop on programmatic self reprogramming of the config registers.

16F: No can do under any circumstances.
18F: Can always reprogram its config registers.
30F: Not a clue. Not a clue!

> Because HVP mode is required, you cannot use a bootloader to change the
> config register, on those parts where this mode is required.

An 18F bootloader can reprogram its config registers.

BAJ
____________________________________________

2004\12\10@073320 by olin_piclist

face picon face
Byron A Jeff wrote:
> 18F: Can always reprogram its config registers.

Not true.  The WRTC configuration bit must be 1.  There may also be a
voltage range restriction on self-programming, but I don't remember for sure
off the top of my head right now.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\12\10@093322 by Byron A Jeff

face picon face
On Thu, Dec 09, 2004 at 08:52:25AM -0500, Roy J. Gromlich wrote:
> Hi Byron:
>
> I basically agree with most of your post, although I don't do MIDI
> so I don't have your need for a separate programming input to the
> chip.  I'm going to snip out a lot of the previous messages so as to
> not tie up bandwidth.

MIDI is representative of the problem, not a specific need.  I believe that
the USART is a high powered precious resource that should be reserved for the
application in most cases. Obviously if the application is going to use it
to talk to a PC, then sharing may be OK. But I find that designing a
bootloader around the presumption of using the hardware USART to be bad
karma.

> [Some snippage]
>
> >>>  using or developing Open Source tools.
>
> I had not found any Open Source PIC programming tools,
> but then I probably don't know where to look.

http://www.gnupic.org is a good place to start. There is a semi active
mailing list too.

{Quote hidden}

But that's the nice thing about having a documented serial interface.
You can just throw up your own application to talk to Tiny's firmware.
As a Linux guy this would have been a presumption for me. I have a core
bootloader application starting with Wojciech M. Zabolotny's linwload
app. I can build new bootloaders by swapping out the default WLoader
interface with something else.

BTW the programming algorithm isn't in the Windows app. It's in the firmware.
A brief look at the 18F firmware doesn't indicate anything that prevents
writing the config regs. So the range checking for config regs is in the
Windows app.

I know I'm advocating reinventing the wheel. But I usually do so because you
end up with your wheel that behaves the way you want your wheel to behave.

>
> >>> A better idea may be to use Tato's PLoader.
> >>> You can find the project here: http://propic2.com/ploader
>
> I will check it out as soon as I get some free time - probably
> over this coming weekend.

I'm just realizing that you're doing 18F work. Tato's loader is specifically
for the 16F819. So unfortunately I don't think it'll fit your needs.

I plan to spend a half day sometime soon updating it for the rest of the
current 16F self programmable chips (16F88, 16F877A). It seems like it would
also be simple enough to program for the 18F. I should be possible to simply
blend Tato's bitbanged serial interface to the programming sequence in the
18F Tiny. I'd still want to rework the serial packet interface because
both still have some issues.

>
> >>> Finally someone that appreciates the power of the bootloader...
>
> Coming from the world of erase the EPROM / burn the EPROM,
> I really appreciated the first uProc development system I had which
> allowed loading the code  into emulation RAM.. What a time saving
> that was, even though the code went away when power went off.

I definitely feel the shortened development cycle. I also like the fact that
you can choose the programming interface instead of being stuck with the one
that the chip is engineered with. Personally I find that WLoaders single pin
bitbanged, half duplex interface is the absolute best. Finally you can get
a serial debugging back channel via the bootloader port.

The only thing that's missing is the ICD. It could be done with quite a bit
of work. But the multiword writes and super multiword row erases makes it
a lot tougher to do. To insert a breakpoint you have to copy 32 words, erase
the row, then write the 32 words with the breakpoint back into place.

>
> >>> But a good command protocol should mask most of the issues.
>
> If (that's a BIG if) you can anticipate the possible changes in new
> chips programming requirements, you can have a parameter file for
> the programmer which has entries for each new chip, telling the
> programmer how to do it.

Not as tough for bootloaders, as the firmware does the actual programming.
But your serial packet protocol must anticipate issues such as multiword
writes and row erases, neither which existed when the 16F877 came out.
Wouter's ZPL sends out a 64 word data packet which solves most of the
multiword/row erase issues. But better would be to simply ask the firmware
what chunk size it wants for data packets and erases.

>
> >>> I strongly feel that the hardware USART should be available to
> >>> the application instead of having to share with the bootloader.
>
> I understand, and even agree to an extent.  As I said, the UART is
> already connected to the computer doing the programming, so having
> the programmer and the application take turns using the RS232 isn't
> a serious problem.

Understood. What I'm trying to say is that I have a problem with bootloaders
that requires the use of the USART. So that means having a bitbanged
interface as an option.

>
> >>> Everyone else requires that you move at least to address 4 or 8.
>
> I almost always write code so the first 2 bytes are a jump to the
> system initialization code, so that isn't an issue.

But it is. The bootloader always has to reside at the reset vector location.
So what happens if the application tries to overwrite that vector?

>
> >>> Only 18F parts can do that. You should read Wouter's
> >>> explanation to why messing with config regs is a bad idea
> >>> even for 18F parts. In short it allows the bootloader to
> >>> potentially disable itself, which is a no no.
>
> I would agree that would be a nasty problem, but the firmware
> you are testing could always find strange ways to disable the
> device being tested.

True. But changing config bits is an easy path to that destination. Even
if the code simply exists in the bootloader, then there is the potential
for the application to accidentally jump into that write.

I'm struggling to see any valid reason why the config regs would need
to be programmatically changed. Can you give a scenario?

> [snippage]

BAJ
____________________________________________

2004\12\10@102618 by J. Gromlich

flavicon
face
Byron:        ( with snips )


> ----- Original Message -----
> From: "Byron A Jeff" <spam_OUTbyronTakeThisOuTspamcc.gatech.edu>
> To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
> Sent: Friday, December 10, 2004 9:33 AM
> Subject: Re: [PIC] reply to Byron A. Jeff re: Bootloader problems with
> newPICs

> > MIDI is representative of the problem, not a specific need.  I believe
> > that the USART is a high powered precious resource that should be
>> reserved for the application in most cases. Obviously if the application
>> is going to use it to talk to a PC, then sharing may be OK. But I find
>> that designing a bootloader around the presumption of using the
>> hardware USART to be bad karma.

I take your point - actually, I kind of like the 1-pin bit-banger idea

> > > I had not found any Open Source PIC programming tools,
> > > but then I probably don't know where to look.
> >
> > http://www.gnupic.org is a good place to start. There is a semi active
> > mailing list too.

I will check that one also - probably this weekend

{Quote hidden}

By firmware you mean the 100 byte bootloader code which is loaded
at the top of code ram space?  I guess I need to look more carefully
at that code.  Thanks

> > A better idea may be to use Tato's PLoader.
> > You can find the project here: http://propic2.com/ploader
> > I'm just realizing that you're doing 18F work. Tato's loader is
> > specifically for the 16F819. So unfortunately I don't think it'll fit
> > your needs.

OK - one less thing for the weekend schedule.

> > I definitely feel the shortened development cycle. I also like the fact
> > that you can choose the programming interface instead of being stuck
> > with the one that the chip is engineered with. Personally I find that
> > WLoaders single pin bitbanged, half duplex interface is the absolute
> > best. Finally you can get a serial debugging back channel via the
> > bootloader port.

As I said above, the 1-pin idea is growing on me.

> > > I almost always write code so the first 2 bytes are a jump to the
> > > system initialization code, so that isn't an issue.

> > But it is. The bootloader always has to reside at the reset vector
> > location. So what happens if the application tries to overwrite that
> > vector?

Good point - should never happen - BUT !

> > True. But changing config bits is an easy path to that destination.
> > Even if the code simply exists in the bootloader, then there is the
> > potential for the application to accidentally jump into that write.

> > I'm struggling to see any valid reason why the config regs would
> > need to be programmatically changed. Can you give a scenario?

> > BAJ

Not much of an issue, but here is how the question came up. The
18F4620 can divide the Watchdog interval by up to 32,768, while the
18F452 was limited to 128.  I use the WD timer as an ultimate escape
to restore operation in case the serial I/O hangs from one of the
sometimes strange peripheral devices we communicate with.
Nothing unusual.

There are several commands our device can execute which require
transmitting a large block of data - if the WD timeout is set long
enough to account for those transfers, it is TOO long for 80% of
the other operations the device carries out. On the 18F452 I had been
handling that by executing CLRWDT commands at points during the
long transfer. Given the increased divisor range on the new chips I
thought I might be able to change the WDTs interval before the big
data dump and restore it afterwards. But when I changed the setting
in the code, reassembled it and sent it to the target board, nothing
changed - the WDT continued to time out after 128 counts, which
is what the EPIC-II programmer had set it to.

Re-reading the Tiny docs told me that it could only change the Config
Bits from the command line, so I tried that.  Still no effect - just the
opaque ERROR! message.  Digging into why nothing changed led to
this thread.

This isn't a problem for my firmware - I was using a fixed WDT
before and I will continue to use it now.  This was all a matter of
curiosity as to whether or not I was doing something wrong which
was preventing the WDT from working as I thought it was supposed
to work.

Thanks for all the good ideas.

Roy





____________________________________________

2004\12\10@104600 by Wouter van Ooijen

face picon face
> But I find that designing a
> bootloader around the presumption of using the hardware USART
> to be bad karma.

In a lot of cases this might be true, but when the normal use of the
UART is to talk to a PC it makes perfect sense to use that same data
channel for bootloading :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\12\10@124300 by Byron A Jeff

face picon face
On Fri, Dec 10, 2004 at 10:26:16AM -0500, Roy J. Gromlich wrote:
> Byron:        ( with snips )
>
>
> > {Original Message removed}

2004\12\10@124706 by Byron A Jeff

face picon face
On Fri, Dec 10, 2004 at 04:46:01PM +0100, Wouter van Ooijen wrote:
> > But I find that designing a
> > bootloader around the presumption of using the hardware USART
> > to be bad karma.
>
> In a lot of cases this might be true, but when the normal use of the
> UART is to talk to a PC it makes perfect sense to use that same data
> channel for bootloading :)

So the ideal bootloading system would have both a bitbanged and a hardware
USART driver. Not in the same image of course, but two different hex files
(or source files) with the same serial packet interface, but different
hardware interfaces.

Again, I don't have a problem with using the USART in the situation outlined
above. But I wouldn't (and BTW you haven't ;-) based a bootloader on that
presumption.

BAJ
____________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...