Created Sun, 23 Jun 2013 14:27:39 +0000 by caroper
Sun, 23 Jun 2013 14:27:39 +0000
I have created three new Bootloaders specifically designed to maximise use of the SPDIP packages on a Breadboard. They are the result of a carefully considered set of compromises that attempt to balance the needs of the bootloader, the needs of the user, the dedicated pins and the limits of PPS (Peripheral Pin Select).
They are: BB32_150_UART, BB32_250_UART and BB32_250_USB
All three are attached to this post in a single zip file.
As can be deduced from the names there are two UART based Bootloaders and a USB bootloader and they target the PIC32MX150F128B and the PIC32MX250F128B devices.
The two UART based Bootloaders use UART2 assigned to Pins RB8 (Rx) and RB9 (Tx). These pins were chosen as they are 5V tolerant on both Devices, allowing the use of any FTDI or USB Serial adapter Boards or Cables without the risk of damage to the Device from exposure to potential 5V signals.
The USB based Bootloader uses Pins RB10 (D+) and RB11 (D-), these pins are set by Microchip and are non negotiable. This does, however, mean that any attached FTDI or MAX232 device normally used on RB8 and RB9 is also available to the USB device as a second serial port (it would still have to be mapped appropriately in your application using PPS but it makes hardware layout easier).
All three have a Bootloader Mode Input (Active High) on pin RB7. If this pin is High when the Device enters reset it will go into bootloader mode when reset is released. If it is Low when the device enters Reset it will reset and execute the User application as normal.
They also have a Bootloader Mode Output on pin RB3, which will toggle at a rate of ~ 4Hz when the Device is in Bootloader Mode. RB3 was chosen because RB6 is Vbus on the MX250 Devices and RB5 is USBID when working with USB OTG. RB4 is available on both Devices but is also used by the Xtal for the RTCC peripheral, which I consider to be far to valuable a Peripheral to be sacrificed for the sake of a Bootloader.
The reason I supply a UART bootloader for the USB device is to facilitate experimentation or developing of applications that use USB HOST or USB OTG Modes. That way the device attached to the USB pins will not need to be physically removed in order to update the program or Sketch that the Device is testing.
Use with MPIDE
I have not yet developed a Boards File for MPIDE, though it is high on my ToDo list, but the bootloaders will work with the Digilent DP32 Board Definitions with the following caveats:
With either of the UART based bootloaders the MPIDE Serial console will be Serial1 not Serial as it is in the USB bootloader.
The PD32_150_UART bootloader frees up an extra 2 pins, RB6 and RB12, however, they are not allocated ChipKIT Pin Numbers in the DP32 Boards file.
The MX150 part also frees up ChipKIT Pin Numbers 0, 4, 5, 15 and 16 as those Pins are not required for Devices without a USB Module. In total that is an extra 7 Pins to play with.
Hacking the DP32 Board
Using a PIC32MX150 part with the DP32 Development Board should be possible, however, you may wish to cut a trace and place a Jumper inline with device Pin 15 (RB6) as the Board will apply 5V (Vbus) to that pin. It should not damage the Device as it is a 5 Volt tolerant Pin, but in doing so you free up an extra pin for general I/O.
Likewise Pin 23 (RB12) will have 3V3 applied as Vusb, by cutting the trace and including a Jumper you will make RB12 available for General I/O.
You may wish to do the same with RB10 and RB11, thus allowing you to Power the Board via USB without getting an Unrecognised Device Error on your PC. It will also free up RB10 and RB11 (ChipKIT pins 4 and 5) for use in your own programs.
The PROG Button is attached to ChipKIT Pin 1 not Pin 17 as it is on the DP32 Dev Board. This should pose no problem as the DevBoard also has a USER Button attached to ChipKIT pin 1 so the functionality is effectively swapped.
As I do not have a DP32 board to test it on and due to shipping costs and exchange rates I don't expect to be getting one soon, I can not confirm the above assertions. If any one who has a DP32 Board would care to try it, please let us all know if it worked.
Updates to existing Bootloaders
It may be possible to update the Bootloader supplied on the Device on the DP32 Board via MPIDE, the same is true for the Preprogrammed Part from Microchip. I have not yet tested a Sketch to do so, as I am waiting for samples of the part to arrive from Microchip, if it works I will let you know.
These three bootloaders should allow any hobbyist or developer to get up and running with the Hobbyist friendly PIC32 SPDIP parts, either on a breadboard, the existing ChipKIT DP32 or their own custom board. They are the result of a lot of experimentation, frustration and gray hair, but I hope by publishing them here, ready to use, I can save others some of that pain.
My thanks to Brian, Keith and others who have helped, guided and encouraged me here on the forum and Microchip for supplying the parts.
For further information, updates and a Breadboard Layout to make maximum use of these parts, as well as insight into using the features of the PIC32MX Family in MPIDE, please subscribe to my blog at [url]http://caroper.blogspot.com[/url].
C.A. Roper and Associates
Sun, 23 Jun 2013 14:30:41 +0000
Have you created MPLAB 8 projects and workspaces for these bootloader? If so, it would be great to get these into the GitHub repo. Is that something you can do? If not, I can take the files and put them in the repo if you send them all to me.
Thanks for your hard work!
Sun, 23 Jun 2013 16:44:45 +0000
I do have projects for them and would be happy to send them to you. I am reluctant to make changes myself as I am a bit of a hacker when it comes to MPLAB and C programming, so would hate to break the rest of the Bootloaders as a result of putting mine in. I assume you have some structured method to do so :)
I Would also like to assign them vendor and Device ID's or is that something that you would do as part of the process?
How would I get the files to you?
Sun, 23 Jun 2013 16:51:18 +0000
Many thanks. It should be the case that the only changes to the existing repo files are additions to the BoardConfig.h file and the new projects and workspaces. Did you need to make any changes to the actual .c files? If all you have are some new sections to the BoarConfig.h file, then it's very easy to merge those into the existing file.
I'm happy to assign new vendor and device IDs - right now, the file in GitHub is kinda the only 'registry' of who's using what.
You can e-mail me a zip file with your project directory if you want (firstname.lastname@example.org) or you can place the files in a Google Drive and share them or something like that.
Sun, 23 Jun 2013 18:44:10 +0000
They are just changes to to the BoardConfig.h file, but I am worried I modified some of the other entries in that file whilst experimenting.
I think the best thing would be for me to download a new copy, make a clean install, add just my changes and then make a set of new Project files from that.
It is late Sunday evening here so it will have to wait till Monday, but it would be nice to have it up there as a resource for others but also as a backup for myself.
I will send you an email tomorrow.
I see in the other thread that Keith has agreed to you posting the DP32 entry, so no need for me to send you that one.
Tue, 25 Jun 2013 14:43:00 +0000
Great thread! I'll be happy to send you a DP32 board to help with testing. If there is something else you need, just let me know. Send me a PM with your shipping address...
Fri, 28 Jun 2013 14:06:20 +0000
Can I get 2 USART, SPI (for ENC28J60 and micro SD), and I2C (5V tolerant for I2C) with your MX150 boot loader? Can I get Chipkit pin mapping table? I want to try develop small board and combine it with custom Arduino (ATMega1284p).
Thanks for your help
Sat, 29 Jun 2013 17:05:24 +0000
Yes you can, or should be able too that is, I have not tried the combinations you request. If you are using the DP32 Board definition then the Pins will be numbered as per the DP32 Device. Take a look at the Digilent page for the DP32, you can find the documentation there. (Sorry I don't have the link to hand but Google will get iit).
You can also look at my blog at [url]http://caroper.blogspot.com[/url] where I show a breadboard layout for the device, a table of PPS settings and an example of useing PPS (erephiral Pin Select).
The I2C ports are fixed but the rest you should be able to remap with PPS.
Sat, 29 Jun 2013 22:47:50 +0000
I found some time to take a look at your requirements and the USB Bootloader would allow it but not the BB32S150 as the 5V tolerant I2C would replace UART2 that I use as the Serial Bootloader Pins.
If you could use a BB32U250 and 5V tolerant I2C and 2 UARTs are essential and you could give up an SPI port, you could move UART1 to where the Second I2C port is and regain the RTCC Module, then use SPI1 and UART2 replacing SPI2.
That may well meet the requirements in this case and has the added benefit of retaining the RTCC.
8MHz Xtal -> RA2, RA3 USB OTG -> RB10 = D+, RB11 = D-, RB5 = ID, RB6 = 5V, RB12 = 3V3 UART1 -> RPB2 = Rx, RPB3 = Tx UART2 -> RPB1 = Rx, RPB0 = Tx SPI1 -> RPB14 = SCK1, RPB13 = SDO1, RPA1 = SDI1, RPA0 = SS1 I2C 5V Tolerant -> RB8 = SCL1, RB9 = SDA1 RTCC -> RA4 / RA5 Clock Xtal
RB15 and RA0 are available for GPIO, probably Indicator LED's and RB7 has a Button attached to select modes etc. One of the Communications channels could be chosen as a Control Interface.
This would make a very nice communications expansion device for a lot of other devices, even a PC or an Android Tablet, with the processing power also providing for Data Encryption / Decryption and Protocol conversion, with the added benefit of a RTCC for time stamping and emulated EEPROM for configuration storage.
If you specifically want to use the MX150 I could build another Bootloader that used RB10 and RB11 as the Serial bootloader, that would also free up 5 extra pins for GPIO, maybe an LCD Display if you give up the 2 LED's mentioned above.
Let me know and I will give it a shot.
I may even build one for myself :)
Mon, 01 Jul 2013 04:20:05 +0000
Thank you very much for your explanation. I've tried to create some images for pin mapping as follows.
1st image is DP32 pin mapping, 2nd and 3rd images are pin mapping for MX150 and MX250 based on your suggestion for this purpose. Are they right?
I think I should try to use MX150 version, because I don't need USB. But can I use PIC32 pins 14, 15, 21, 22, 23 for digital pins (they are USB in MX250)?
Additional, I will use external RTC IC because need backup from 3V battery. So, I can use PIC32 pins 11 and 12 as digital pins, right?
Table design idea taken from http://blog.kemushicomputer.com/2013/06/chipkit-dp32.html
Tue, 24 Jun 2014 07:41:06 +0000
Hi caroper and everyone,
I download the zip file many times, but can't open it. Could you please up-load it again?
Thanks in advance.
Sat, 01 Nov 2014 00:21:27 +0000
Have been trying to download the BB32_bootloaders.zip but it keeps saying the file is corrupted when I attempt to extract the hex files.
I am interested in the BB32_150_UART version.
Sun, 02 Nov 2014 23:36:54 +0000
Having problems with extracting the BB32_bootloaders.zip file, when I try to open the zip file is says it cannot open folder and the file is invalid.
Thu, 04 Dec 2014 15:30:25 +0000
I've sent caroper a PM but he didn't response. I would be nice, if someone has a backup of the bootloders for re upping them into this thread?
Fri, 19 Dec 2014 13:34:44 +0000
This is the copy I had at the end of Feb 2014. I've no idea if things have changed since then.
Mon, 22 Dec 2014 17:44:15 +0000
Dear Graham! Thank you very much for re upping the bootloaders!
Tue, 14 Jul 2015 12:22:06 +0000
Hi All, Sorry for not responding to this thread for so long but I have not been working with the Chipkit for some time and missed the posts.
I also just tried to open the original zip and get the same message, very strange as nothing has changed, I never thought that zip files were biodegradable over time :)
The version that Graham posted works fine and is still current, thanks for that Graham. I will try to find what is coursing the old link to break and fix it if possible.