Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Hi,
I'm new to forums so please forgive me if I break any rules.
I've made a Time/Date/Outside and Inside temperature display for my caravan (using a PIC 18F2520 micro and programmed in assembly), it works OK except that the 20x2 LCD display is too small. When Geoff Graham's article was published in Silicon Chip on the Super Clock I decided to give it a go. I've already had some experience (a little) with the Maximite and Colour Maximite.
I thought that I knew enough to get me through this project so purchased the kit from Silicon Chip. When assembled I thought that I should take it slowly so decided that I would program one of my 32MX170F256B chips with V5.2 of MMBasic, using Micromite_Plus_5.2.hex. This I did successfully with my ICD3 programmer via the ICSP port of the kit PCB and through my own jig connected to the ICD3. I was hoping to use some of the commands of MMBasic, even to just get the MMbasic prompt, just to check if all seemed OK. After checking supplies at the correct points on the PCB I connected the USB/Serial converter to the computer and the PCB. Nothing happened on Tera Term (set up for 38400 baud, correct COM port etc) after pressing the the Reset button, entering Ctl C, Return key. The TX LED on the USB/Serial converter flashed on key presses, but the RX LED did not flash. I programmed another 32MX170F256B with the same results. This was all done without the LCD plugged into the kit PCB.
I plugged the kit chip into the PCB and could get the MMBasic prompt and could do simple things (eg PRINT 1 + 2) with 3 as a result. I the plugged the LCD into the PCB and then went through the Micromite LCD Backpack instructions for setting up the LCD, OPTION LCDPANEL ILI9341 etc, GUI TEST PANEL, OPTION TOUCH, GUI CALIBRATE - these worked Ok but I could not get the clock to run.
I finally programmed one of my 32MX170F256B chips with SuperClockFull.hex, plugged it in, checked serial communications with MMBasic with success, could run the LCD and TOUCH tests and finally the Super Clock software ran. As I had no RTC or GPS fitted the program ran as described finally running using the internal clock of the 32MX170F256B.
Now to my questions - why couldn't I access the MMBasic when just programming it alone, what didn't I do correctly, was it loaded into the wrong part of the32MX170F256B's memory?
As far as the kit 32MX170F256B, it appears to me that it wasn't fully programmed, or could there be another reason, a defective chip maybe, maybe something thaa I may have done?
If you have read all my ramblings above thank you, hopefully you can give me some answers.
Ken
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 772
Posted: 01:17am 28 Aug 2016
Copy link to clipboard
Print this post
Hey Ken.. Welcome to the forum..!
I think the main thing you did was to use the wrong HEX file when programming..
MM Basic files have two different kinds, depending on what class of PIC IC you are using... For the "170" core, use the Micromite_5.21.hex file instead of the "plus" version, which is made for the "470" class cores...
Should work ok... Post back your results...
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948
Posted: 01:41am 28 Aug 2016
Copy link to clipboard
Print this post
Hi Ken,
As Zonker has said, you need to program the NON Plus version of the hex file. This will then work ok on a 28pin (or 44pin) MicroMite.
The Plus version is for the 64pin and 100pin MicroMites.
Thanks for that, spot on, that solved the problem.
The ironic thing about it is that I started with the Micromite_5.21.hex file, I used MPLAB IPE V2.10 but when I programmed the chip with this file MPLAB IPE programmed it and reported that it was programmed and the Verify was OK. When I used the VERIFY command it reported a failure with the error message :-
Verifying...
program memory
Address: 1d000400 Expected Value: ffffffff Received Value: ffff0000
Verify failed
2016-08-28T21:39:47+1000- Verify failed.
With this message I assumed something was wrong and didn't even try to talk to MMBasic and tried the 'plus' version which gave no errors for the Verify command - can you see a reason for the failure message?
Thanks for reply, when I replied Zonker's suggestion you had not posted your reply.
Yes you both had the correct answer, as I replied to Zonker I started with the NON 'Plus' version but because of Verify failures I used the other file, guess that's why the pre-programmed chip worked as far as MMBasic was concerned, just got to figure why the program didn't run.
Now that I know what the problem with me connecting to MMbais I can and try my own program now.
Thanks for your help, regards,
Ken
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948
Posted: 02:19am 28 Aug 2016
Copy link to clipboard
Print this post
I have found (as have others here) that the Verify function on MPLAB IPE is not very 'reliable'. As a newcomer this message would indicate you may be doing something wrong - but rest assured that programming the correct HEX file onto the PIC will work 100% in IPE when just using the 'Program' option.
One other thing to be aware of is that you need a vCap on the relevant pin - without it you WILL run into issues (and MMBasic will not run).
Have Fun playing - and post any 'issues' you have as there are plenty of friendly people here willing to help out . . . .
WWEdited by WhiteWizzard 2016-08-29
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 03:26am 28 Aug 2016
Copy link to clipboard
Print this post
My experience is that the verify is very reliable. :)
In the case of the micromite you should be aware that when it runs the first time it changes some flash program memory.
So after you program it, the code runs, that changes the flash contents and then a verify will tell you that it fails because the contents of the flash is not the same as the hex file.
You can test this by reading a chip with the micromite firmware in it, save it.
Then do a compare with the original hex file.
When you use the hex file you just read from a working micromite, use that one to program the next one. A verify will then not give an error, because the firmware sees that the flash memory is already setup and skips the step to change the flash content.
Edited by MicroBlocks 2016-08-29Microblocks. Build with logic.
Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667
Posted: 10:50am 29 Aug 2016
Copy link to clipboard
Print this post
I've certainly seen that; and assumed it was my incorrect usage, as after a few cases of seeing a verify fail, I found the chip to be fine.
That explains a lot.
Phil.Edited by Phil23 2016-08-30
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948
Posted: 11:02am 29 Aug 2016
Copy link to clipboard
Print this post
You are 100% correct - but for 'newcomers' to the MicroMite that are loading their own firmware (and have some IPE experience), the failed Verify message will cause an element of doubt in their head that they are doing something wrong.
Not sure if this is mentioned in the MM Manual - maybe worth asking Geoff to add a sentence if it isn't!
Thanks for all your replies and information, it has helped me a lot, unfortunately for you all you may have to put up with some more of my long winded questions in the not too distant future.
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post
