[SOLVED] PIC18F4685 config bits - Page 1
Forum section: electronics / general

author: MrAureliusR
author_rank: Unknown
timestamp: October 17, 2013, 03:53:49 am
content: Anyone having the same problem with the TL866 see my post further down---------------I've finally gotten my MidiBox SID kit in the mail. I did a stellar job soldering and assembling the unit (it looks as good as the examples done by pros online -- I'm very proud of myself). I meticulously took my time, made sure each step and each part was correct before proceeding.However, I seem to have hit a brick wall. I got over-eager before it arrived, and even though I had three different 18F4685s, I programmed one with (what I thought) was the correct procedure -- thinking, if anything were to go awry, I could simply erase it and try again. This has always been my experience with AVR -- you erase the chip, everything goes to FFs, and the config bits go back to their defaults.So I programmed the first one incorrectly, and when for some reason hitting erase didn't clear some of the config bits, I shrugged and programmed the next one, which, to my dismay, did the same thing. I then realized that I had previously (in my over-eager excitement at getting my PICs and also my MiniPro programmer) 'filled' the chips with 'random' data to test that they wrote and erased properly. This must have also added junk into the config bits? Now pretty sure that either I or the programmer was doing something wrong, I borrowed a PicKit3 from someone, and burned JUST the bootloader, and nothing else, using ICSP, as instructed by the guys over on the Midibox website. This is the one I left alone until I built the kit, figuring everything would go smoothly.Of course, Murphy got me, and now I'm %200 sure that I've got all the hardware set up correctly but the chip isn't programmed properly. When the MIOS (that's the MidiBox OS) bootloader first loads on the chip, it's supposed to send out an upload request over the MIDI lines every couple of seconds. You open up MIOS studio and it will see those requests coming in. Then you can use MIDI to program the chip with the proper program depending on which synth you are building. This is the process I was trying to bypass initially, thinking (apparently foolishly) that there's nothing that this app can program over MIDI that I can't program with my MiniPro...So my question is --- are the config bits in PICs one-time programmable? Obviously lock bits are, but what about the rest of them? If the lock bits were set I shouldn't be able to program or erase anything -- which I am able to without a problem. I've done exactly as instructed on their website -- I start with a (so I thought) completely blank chip, and then load the .hex file for the bootloader, and burn it. I've burned hundreds of chips with my MiniPro with no problem (they were AVRs, how foolish of me to think there was no difference with PICs). I have a feeling it may be just a software problem that it's not clearing the config bits, but when I try to burn the .hex file after blanking the chip, when it gets to the config bits it gives me an error: BUFFER_VAL = 0xFF CHIP_VAL = 0x00 .. which makes me think it's unable to clear them for some reason?Please tell me I'm wrong, and that I don't have to buy a few more 18F4685's just to get my MidiBox working... sigh.EDIT: Just realized that in the MiniPro software, when you try and blank check an 18F4685, the 'config bits' checkbox is greyed out... making me think they are OTP. Like, what the @$^$ was Microchip thinking?!?! OTP config bits??! Please tell me this is my programmer! I still have the PicKit around, maybe I'll try that again...

author: mazurov
author_rank: Frequent Contributor
timestamp: October 17, 2013, 04:24:46 am
content: You should always be able to erase a PIC.

author: MrAureliusR
author_rank: Unknown
timestamp: October 17, 2013, 09:03:32 am
content: I can erase everything but the config bits. The User ID field, data memory and code memory (EEPROM and Flash) are all erasable. For some reason the config bits aren't clearing.

author: MrAureliusR
author_rank: Unknown
timestamp: October 17, 2013, 09:41:10 am
content: I did it!For anyone trying to build a MidiBox in the future, using a PIC18F4685 and a MiniPro TL866CS/A ... when you load the bootloader, like any other hex file, it will try to put the values in the config bits that it DOESN'T set to FF. This, however, is wrong. Simply load the bootloader, program the chip, then UNCHECK 'erase before'. Then find Clear All Buffer in the menus (this is the important step as it will return the config bits to default values and clear all the junk that was added). Then manually check off the following config bits:IESO - FCMEN - FOSC3 - FOSC0 - BORV1 - WDTPS2 - WDTPS1 - LPTIOSC - PBADEN - LVP - XINSTAnd then when you click the program button, uncheck everything but the config bits checkbox (so that's the only thing you're burning) and then program it.Also make sure the USER ID field is all 0s. And away you go! Throw the chip in the CORE module, hook up both MIDI IN and OUT to whatever your PC MIDI interface is (I'm using a TASCAM US-122 mkII and it works great) (EDIT: The US-122 ended up causing major headaches, I then realized it's on the MidiBox blacklist. Switched to an M-Audio MIDISPORT 2X2 Anniversary Edition - works great!!) Open up MIOS Studio, make sure you select the proper MIDI IN and OUT sources (in my case the TASCAM) and you should see a few entries appearing on the MIDI IN side every couple of seconds. That's the bootloader sending a download request. Also, if everything is hooked up right, even before you get into MIOS Studio if you have a hardware LED indicator, you should see MIDI IN flashing every couple of seconds.Bravo!

author: dannyf
author_rank: Super Contributor
timestamp: October 17, 2013, 10:50:04 am
content: QuoteIt looks like they didn't fully specify the config words in the code and relies on the user to manual set/clear them at programming time. A bad practice.

author: MrAureliusR
author_rank: Unknown
timestamp: October 17, 2013, 11:20:50 am
content: Quote from: dannyf on October 17, 2013, 10:50:04 amI have a feeling this might be a quirk of the TL866A/CS software. I know from looking at the changelogs they've had problems like this before, so it wouldn't surprise me. I should go check if there's an updated version of the software..