Programmer/Bootloader concepts

[Rusttree]

I'm having some difficulty getting my head around the inner-workings of programmers and bootloaders.

I've had a bit of experience playing with microchips in the past, but always as part of a kit. I buy a kit, build the cicuits per the instructions, write my code, hit the "go" button, and the uC has my program in it. No understanding what's happening after I hit the "go" button. So far, everything I've done is using Motorola's 68HC11.

A few days ago, I decided to look into PICs. Specifically the 16F88. When I started reading about what I would need to use the chip, the concepts of bootloaders and programmers became an issue. This is where the confusion set it. The HC11 seemed to be ready to go out of the box. The extent of the programmer seemed to be nothing more then a MAX232 built into the cable that came with the kit. When I read about PICs, however, there's a lot of talk of loading a bootloader into the chip beforehand. And then the bootloader intializes the chip to accept a program.

One of the concepts I'm trying to understand now is what is the purpose of loading a new bootloader on the chip? Doesn't the PIC come with some kind of bootloader already installed? And what is the primary difference between the HC11 and a PIC when it comes to loading a program? From what I've experienced, it seems the HC11 was match easier to program. No specific "programmer" hardware necessary besides the MAX232 that converts the serial port's 12V to 5V.

All of these questions are leading me to want to build my own programmer. I've found plenty of DIY examples online, but none of them explain the purpose of the components in the circuit. I guess, ultimately, what I'm looking for is specifically what signals does the microchip expect when initiating communications through the serial port. What wakes up the chip and make it understand that data is coming. I have read through the relevent parts of the PIC's datasheet (at least the parts that I thought were relevent), but the information is written at too low of a level for me to understand - the Catch 22 that you have to understand the concept in order to understand the concept.

I have a bunch of more specific questions here, but I think they would be too much to include now. Hopefully, I'll get those cleared up later in this thread. Thank you!

-Dan

 

[philba]

the standard F88 (or any other PIC, for that matter) does not come with a bootloader so you have to program one. You can get very cheap programmers, kits or build your own. I've always thought there might be a market for chips with a bootloader built in.

take a look at sparkfun.com - they have several programmers that aren't too expensive. You could also look up JDM style programmers on the internet. Take a look at the sticky posting in this forum. it answers a lot of your questions. https://www.electro-tech-online.com/threads/pic-newcomers-please-read-upd-0xd1.15035/

The way a bootloader works, the bootloader usually takes control upon reset and if there is nothing trying get bootloaded on the serial line, it transfers control to what ever program is loaded. If it sees a program trying to be loaded, it reads the data and writes it into flash memory.

 

[akg]

as far as i understand , bootloader is an optional component which enables to modify the program code 'on-the-fly' .or otherwise use icsp
btw , i use jdm type programmer.

 

[Rusttree]

Thanks for the info on pre-made programmers. What I'm trying to do, though, is figure out what a programmer is doing while it's programming so that I could possibly learn enough to build my own.

Also, why even have a bootloader? If you can communicate directly with the chip to load a program anyway, what does the bootloader do to make things easier?

 

[akg]

What I'm trying to do, though, is figure out what a programmer is doing while it's programming so that I could possibly learn enough to build my own.

well..for an energetic programmer it would be the first thing to come in mind..but a second thought ... isn't like 'reinventing the wheel' ?,since lots of programs are already availabe freely .

 

[philba]

Thanks for the info on pre-made programmers. What I'm trying to do, though, is figure out what a programmer is doing while it's programming so that I could possibly learn enough to build my own.

Also, why even have a bootloader? If you can communicate directly with the chip to load a program anyway, what does the bootloader do to make things easier?

the programmer hardware is only part of the process - you will need to have a different algorithm for each chip. go to microchip's site. each PIC has a programming document that describes what you have to do. The electrical part is relatively easy. programming software is much more complex. search for device name and "programming spec". Here's the one for the F88 - https://www.electro-tech-online.com/custompdfs/2006/05/39607b.pdf

It is true that you don't NEED a bootloader but even an in-circuit programmer has some drawbacks. in particular, the cable must be fairly short. a bootloader cable can be quite long (rs232 spec). Thus, it is far easier to update if it's installed in an inconvenient location (like a project case...). I've actually bootloaded over a lan connection - pretty cool. the pic is in my basement and I was on the second floor. I know of several people that bootload over a wireless connection (though that takes some extra effort to ensure data/code integrity). Microchip's own programmer/debugger (ICD2) uses a bootloader.

If you want to build your own programmer and you are fairly capable, here is the design to go with - **broken link removed** It's an ICD2 clone. It uses a bootloader to load code specific to the PIC being programmed. You will still need to burn in the bootloader. The ICD2 will program just about any PIC since it's a clone of the standard microchip programmer/debugger and runs all their software. It also interfaces to MPLAB, their IDE. You probably should first try a JDM style programmer, though.

now aren't you sad you asked...

 

[Rusttree]

Thanks philba, I think the "Programming Specification" document is along the lines of what I'm looking for right now. I appreciate the pointer. I'm sure this was answered in another post somewhere else, but since you brought it up, why the limitation of cable length?

akg, I would agree with you if I had a general understanding of what is happening during the programming sequence. But since it's a blackbox to me right now, my technical curiosity drives me to learn what's going on. My guess is I'll get to the point where I can build a very crude programmer that "sort of" works. After I've satisfied myself that I comprehend the bigger picture, I'll probably go ahead and use a ready-made kit programmer.

-Dan

 

[kjennejohn]

Hi there, rusttree.

Earlier processors had to have a programmer to change voltage levels within the processor's code memory in order to impress the code to be used later. Some present day chips (the PIC 16F87x and some 18F parts come to mind) were given the ability to run code internally and write code within themselves. This self-programming code is the boot loader. The catch is, the bootloader itself is programmed into the processor with an external device, namely, the programmer.

After that is done, upon reset, the bootloader comes up and initiates contact with a host (usually a PC) over a serial port with predefined pins set up by the bootloader itself at initialization. If the host responds with the proper "handshake", then code download commences until the host indicates there is nothing else to send. On the other hand, if the host is not there, after a small time out, the bootloader tries running any code already burned in the chip. If nothing is there, the bootloader just spins its wheels. So, you can simply add a serial port to your design and reprogram parts in the field or lab with a PC, with no fancy voltage circuits. Even your customers could do this.

Every processor has an "origin" address, that is, an address it jumps to after reset which is the starting point for instructions. With a bootloader present, this usually points to some place high in memory where the bootlaoder resides. The loader actually loads your later program just a few address spots above its starting address. This is where the bootloader tries to start code from after reset when there is no host to talk to.

The tricky part here is how to use those pins the bootloader uses for serial communications after it's done its job. You can't USUALLY have other signals connected to these pins because they will interfere with any downloads later. Most designers of development boards in this situation use a collection of headers and jumpers to isolate one from the other. Some go so far as to use solid state circuitry to isolate the signals and use the serial port hardware handshake signals to control these isolation circuits.

Another consideration is the amount of memory the bootloader uses. This subtracts from the total memory available. At some point, if your program grows enough, you will run up against this code at the top of the memory space. You will either have to get a bootloading processor with more memory, or sacrifice the bootloader code and start programming with an external programmer to regain the space.

Seems to me I have seen mention of an application note (usually starts with "AN###") at the Microchip site that explains how make programmers for their processors. You could try doing a search there.

Hope that helped you.
kenjj

 

[philba]

ICSP cable length issue - I'm not sure how long you can make it. Most programmers recommend short (6 in springs to mind). I know that it can be subject interference - it's neither shielded nor twisted.

On the serial I/O pin issue - I often use serial I/O in the final system so it's no loss in that case. With ICSP, you have a similar problem isolating the PGC and PGD pins. there are lots of tricks for sharing though it's sometimes kind of ugly.

typical boot loaders aren't that big, 256 words or less. tiny boot is 100 words.

Note also that many PICs aren't capable of writing their own flash and thus cant support a BL.