Mloader help needed, PIC18F26K80 not supported?

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 6.

Moderator: Benj

Post Reply
Ras
Posts: 37
Joined: Sun Mar 30, 2014 9:27 pm
Has thanked: 10 times
Been thanked: 10 times
Contact:

Mloader help needed, PIC18F26K80 not supported?

Post by Ras »

I'm on a new project trying to make sense of new, to me, tools: EB006V9 programmer, Ghost technology and the mLoader program... the project is a UART-CAN bridge based on PIC18F26K80. Needless to say I run into trouble almost immediately and spent time trying to figure out the issues without much luck.

Specific to this topic... I have the hex file and the chip is inserted into the EB006v9 but do not know if it gets programmed. More so I do not understand if the EB006v9 module works or not.

I load the HEX file then try Autodetect: it says unable to communicate with target. I press Send, says I need to select the chip but the chip I'm using is not available in the <select chip> drop down list. I edited the 8bConfigData.csv (copied the 18F2680 and renamed as 18F26K80). Now I can select the PIC, press Send, it says "the chip could not be detected. Click OK to use specified, D10 flashes a few times and the progress bar shows some activity. Did it program the chip? There is a warning "Flash memory not verified - may be due to code protect). Press Execute does nothing (MCLR high, OSC not running, shouldn't it?). Press Erase, says wait then complete, did it erase? Lastly press Update Bootloader brings up a window displaying version 6:1:9:7. OK this window and an "USB not open" error pops up then "Close programming mode failed" message. I am attaching 2 JPGs to clarify my action sequence.

So what next? Can Matrix add support for this chip in the mLoader? Should I be expecting 19.66MHz on the OSC pins? What should I expect when pressing Execute?

I feel very unproductive at the moment. Please help!

I am using a 9V external power adapter and installed the Matrix supplied driver. The EB006v9 configuration consists of J11 (USB/PSU) set to PSU position (towards the centre of the board), J15 (3V3 or 5V selector) set to 5V (centre of board) and J18/19 selecting the 19.6608 MHz OSC (towards the edge of board).

Plugging the 9V adapter brings in a EB006 Multiprogrammer using Matrix driver 1.0.0.4 as a Custom USB Dev in W7P Device Manager. On the EB006v9 board the D6 LED is on. I measured 5V and 3.3V on the chip. The MCLR line is high. In mLoader the EB006 picture comes up. This indicates that the programmer board works and communicates with the mLoader program, shouldn't it?
Attachments
mLoader - USB not open error.jpg
mLoader - USB not open error.jpg (56.23 KiB) Viewed 4295 times
mLoader - action sequence & feedback.jpg
mLoader - action sequence & feedback.jpg (124.62 KiB) Viewed 4295 times

User avatar
DavidA
Matrix Staff
Posts: 1076
Joined: Fri Apr 23, 2010 2:18 pm
Location: Matrix Multimedia Ltd
Has thanked: 58 times
Been thanked: 258 times
Contact:

Re: Mloader help needed, PIC18F26K80 not supported?

Post by DavidA »

Hello Ras,

Unfortunately that chip is not supported by the EB006v9 board. You can see which chips are supported on the datasheet of the EB006v9.

http://www.matrixtsl.com/resources/file ... 6-30-9.pdf

Sadly, adding it in at this point would not really be feasible.

User avatar
QMESAR
Valued Contributor
Valued Contributor
Posts: 1287
Joined: Sun Oct 05, 2014 3:20 pm
Location: Russia
Has thanked: 384 times
Been thanked: 614 times
Contact:

Re: Mloader help needed, PIC18F26K80 not supported?

Post by QMESAR »

DavidA wrote: Unfortunately that chip is not supported by the EB006v9 board. You can see which chips are supported on the datasheet of the EB006v9.
I do not want to sound bad or critical however I am a bit disappointed in the EB009V9 board I bought 2 of them and
I can all most not program any of the newer PIC devices
PIC16F1508 and the PIC1826K80 are both supported in the compiler but Mloader and the EB009V9 does not support them it is a useless for me as the debugging feature is lost besides the normal programming

It seems to me that most PIC tool vendors start of with PIC and then at some stage they switch to Arduino and then the PIC tools get left behind, I notice this in Martix a bit too and I changed from mikroElectronica to Matrix because of this reason too they were excellent till 2 years ago then they started with arduino now PIC support is very slow
It seems a guy must pay for the Microchip tool and have constant support this then PIC is the main line and then something else does not work for developers like myself

Regards

Ras
Posts: 37
Joined: Sun Mar 30, 2014 9:27 pm
Has thanked: 10 times
Been thanked: 10 times
Contact:

Re: Mloader help needed, PIC18F26K80 not supported?

Post by Ras »

Well Matrix, since it is not currently supported is it not possible to add this support for this chip into mLoader and Ghost? It just makes sense since FC6 supports the part...

Also, is it not possible to list the specification for the configuration files i.e. 8bConfigData.csv and the like so that anyone can add programming support for new parts? I am assuming that programming is done using the ICSP protocol/interface so it should not be a problem whatsoever.

Lastly, one can buy, and one can have any number of PIC ICDs (from Microchip, CCS, Mikroelektronika)... more or less all work based on the same idea and hardware: connect (ghost) the ICSP signals to the chip and program the chip, disconnect (ghost) the ICSP signals from the chip and using the internal debug resources present in the chip allow one to step, break etc. Since we have all the above in house already I was hoping that adding the EB006 will allow us to debug from inside FC... is that too much to hope for? Certainly not, so why not support the tool and your clients with stable, robust and up-to-date tools?

There is no intent here to be rude but there is a lot of frustration accumulated over some time while dealing with FC tools and hardware that do not seem ready for consumption yet. FC's promise is to simplify one's life, make a project happen in short cycle... this does not work if one spends time with debugging the environment, doest it?

Post Reply