bangbang

I'm using 1455 and I can't re-program without unplugging and plugging the USB cable. Reset button will not do the trick.

Hey, that's a strange behaviour. Have you checked your silicon revision against the errata document? From memory reset had an internal pull-up, but maybe try adding one. I'll run some tests at my end, my dev board didn't have a reset button, so maybe something I overlooked.

I haven't been able to reproduce your issue at my end. Not really sure what could be doing that.

I have a pullup on MCLR pin. My device may or may not be bus powered. The RESET button works in either case to restart my code. I'm running Windows 10 and Windows will not enumerate the device unless I unplug the USB and plug it in again. I have to release the BOOT button a fraction of a second after plugging the USB or it will not be recognized and I have to unplug it again. My code does not use the USB and I explicitly disable USBEN.

Sounds like your bootloader button (RC4) is floating? Or possibly a pull-up, instead of pull-down?... Make sure you're using the latest bootloader version, I just updated the bootloader and released the code. If you open config.h and main.c you can see how the bootloader uses the boot button.

Hi, I am interested in making a Mass storage class device using PIC18F25K50. I am not interested in the bootloader part. I looked at the XPRESS example from microchip. The microchip example is a composit device with MSD and CDC. I only need MSD. I can read the readme.html file if I run the example in composit device mode but the file comes out empty when I modify the USB descriptor to make a MSD only device. It will be a great help if you can post an example code that shows how did you get MSD to work.  Any help is highly appreciated

Hey, I have posted MSD examples using my USB Stack on GitHub. https://github.com/johnnydrazzi/USB-Stack . Hope it helps.

Thanks. I got it working

Hi Johnny back to you again....
I did several tests with the PIC16F1455 without any positive results. Every time that i put the HEX file in the drive the pic restart and back again to the drive. That with your test program and mine.
I test the PIC18F14K50 and all was ok !!!
My set of PIC16F1455 are very old may be the first release, I will buy new IC may be my old one have some hardware bug.
Just another question about interrupt vector it's mapped at location 0X2008 and 0X2018 ?
Last question, I need to remove manually all data from address 0X000 to 0X1FFF from HEX file, the compiler non skip automatically any suggest?
Thank you in advance for your replay.

Hey Igor, I'll check the location and get back to you, sounds right... Haven't come across the offset not working before, might need to update XC8, you can modify the hex file if you get desperate... This is an interesting problem you're having, I only tested the bootloader on a PIC16F1454, possibly there is some difference causing this. I'll have to get my hands on a PIC16F1455 and see if I can find the problem.

John.

Hi Johnny, just back form my business trip and did some test:

prepared a blink led program

1)  test PIC16F1455 DEVICE REVISION ID=1003 - not work, the software initialize correctly, I can see the drive, I copy the file but after restart nothing happen.

2)  test PIC16F1454 DEVICE REVISION ID=1006 - work, the software initialize correctly, I can see the drive, I copy the file and led start blinking.

I do not have any PIC16F1455 with new revision, I do not know if there are a bug in the firmware or in the chip.

3) test on PIC18F14K50 are ok too!!

Will be good if the firmware skip the boot section location if the compiler prepare a HEX file from the location 0x0000 with value 0x00 to location 0x1FFF.

Best regards Igor

Thanks for the tests Igor! Yeah revision ID=1003 has a silicon bug. The errata says that the device can't write to flash with internal clock speeds over 4MHz. 

http://ww1.microchip.com/downloads/en/DeviceDoc/80000546F.pdf

That explains your problem. Unfortunately there is not a fix for this (that I'm aware of) as USB needs to operate at the same time as writing to flash. And USB needs 48Mhz, which only operating at 16MHz can provide.

John.

Any chance you can check your ICs revision? The errata does mention flash writes not working on clock frequencies > 4 MHz for revision A2.

Hello,

I really like your project, I programmed a PIC16F1455 with the bootloader NO_XTAL, and all it's ok, When I reset the board I see the USB drive in my windows 10. I try to download the test example but nothing happen. Every time I restart the board I see the disk but the test program do not start.
Can you please telling me what the test program do? You use the led?

Thank you in advance Igor

Hey Igor, I may have messed up the test file. I'll verify this. When you start the bootloader does your led flash fast three times on RC5? Also do you have the pull-down resistor on RC4?... I'm able to create a version of the bootloader and test file to work on a dev board I have, the button and led are on different pins for that. I may have forgot to put it back to normal version before compilation.

Hey Johnny thank you for your prompt replay, yes I followed all instruction and pullup and pull down was installed, in any case today I will bouble check but I’m quiete sure all it’s ok. Thank you fot your test.

Best regards

Igor

a quick test you can do is create your own blinky test file and make sure code offset is 0x1000.

Hi Johnny,

thank you very much for your test, I will try to figure out, as soon as I found the problem I will write to you.

Hey Igor, just tested the booloader and test file together, seems to work fine here. 

Currently I only have one pic for development, if I charge the booloader could I re-record another program in the section that is recorded by the bootloader? I do not want to lose the pic in case of having problems with the bootloader

ah, I understand. The write protection bits in the config words just prevent your user code from being able to overwrite the protected areas. You can still write over it again with a programmer. The code protection bits prevent a programmer from reading back your memory contents (stop people from stealing your firmware). When I was first learning about PICs, I made the same assumption.

Hello, excellent work ... but I have a question, if I load the .hex in the pic, I could not load a different program because of the write protection?

Hey, thanks. The bootloader protects itself and the configuration words when loading your hex file. Just be careful with your user code, that you haven't written code that writes to locations in flash that have the bootloader or config words. Some of the bootloaders have protection from this where possible, but it wasn't possible for all of them.

I recently acquired a pic18f24k50 to make tests, Do you have a bootloader without code protection for this pic?

Not sure I understand your question. The user space is not write protected. It's a bootloader after all.

Great news for the 18F14K50, I should test it as I have some of them, just need to find some time :)

I look forward to your feedback. The latest version has a EEPROM.BIN file you can open in a hex editor. You can read and modify the EEPROM through that file. I'll update the instructions tonight.

This looks great! Are there any plans to support more controllers? Or to publish the code, so that others could add additional controller support? 

Cheers Alex. I have a few in mind I want to support. PIC18F25/45K50, and PIC16F1455. I have already designed some modules for 25K50 and 1455. I think the J series will be easy to port. I had a go at the 45K50 the other day, with some difficulty. I'll keep trying on 25/45K50, they seem to be popular.

Very nice ! Will you keep your code closed ? (which I understand perfectly)

Thanks Muth. Hopefully it gets used other than just me. I'm still undecided about opening the code.

Yeah, totally your call. :)
If another data point is useful, I would totally retarget this for a different chip - Maybe PIC18F14k50 - If I had the source.

I'm working on porting the 45K50 next, that should be similar right?

That'd be cool. That's a good family.

X5K50 parts are now supported.

So what's the current status, is it working yet?

Hey Dave, yeah firmware for X7J53 is working well. Plan on compiling with XC8 Pro some time over the weekend to see how small I can get the bootloader. I'll release the hex after that hopefully.