Upgrading from V2 to V3 (not accepting MIOS upload)

[mjproc]

Hi

  I received my V3 parts today, and immediately soldered the IIC Midi together and mounted the new pic (4620)

Trouble..... omph.... I can't upload mios to the new pic.  After heavy forum search (4 hours....) I still have not solved this puzzle.

Facts:

Core module with 4620 pic

The 4620 was ordered with PIC ID 0000000000000000

DIN and DOUT as mbseqV2

LTC module attached  on J11 (showing both midi in and out activities during upload attempts, and only Out when idle)

Tried both and USB midi interface and a sblive midi io

Poweradapter: 7,5V/1A (as used in V2)

When trying to upload mios_v1_9d_pic18f4620.hex, I get error from mios studio:

Starting upload of mios_v1_9d_pic18f4620.hex

Hex file contains code in MIOS range, forcing reboot!

Received Upload Request

Sending block 00000400-000004FF

Error: Received unexpected Upload Request

..

..

Sending block 00000500-000005FF

Error: Received unexpected Upload Request

Aborting after 16 errors

Midi monitor In:

...

00000006215161 ms | Sysex message: F0 00 00 7E 40 00 01 F7

...

Midi monitor out:

timestamp [unknown] | Sysex message: F0 00 00 7E 40 00 02 01 00 00 20 18 7B 62 5F 00 45 0F 7F 7F 41 5D 50 17 40 0C 00 6C 73 78 4F 2E 6B 1F 45 7A 67 56 03 66 42 3D 3A 4C 34 14 1B 13 63 21 1D 54 00 5A 09 75 62 0F 50 79 2D 04 7D 06 13 0B 59 7F 71 38 5D 57 7C 22 00 70 73 77 3F 2F 0B 1F 3C 7A 7D 59 7B 6F 57 6F 4F 5F 3D 3E 5C 7E 03 6A 03 60 30 3E 50 26 03 05 75 02 70 18 3F 28 48 01 3B 62 78 3F 7B 66 17 45 7F 5E 71 3E 6F 7D 7B 0B 77 7F 70 18 5F 2F 7F 03 45 01 7C 18 2C 28 13 61 43 62 41 3E 01 10 00 10 0E 6B 1B 5E 29 20 0A 68 05 68 11 3D 40 5F 42 69 3D 29 3B 01 4F 06 0B 2F 1E 48 33 32 0D 40 3B 1E 26 77 43 59 62 36 36 00 05 00 6E 2A 1D 45 12 72 07 5C 0A 60 2B 21 47 21 38 28 41 61 30 2F 06 74 05 01 78 17 25 0E 62 49 3A 03 41 20 1A 58 1C 45 61 56 14 3B 0B 25 30 53 2B 37 6A 4A 11 67 02 5E 51 6C 29 15 70 3D 43 3E 02 53 03 1D 41 47 42 2D 6C 04 3C 1E 6E 60 37 60 02 53 03 5D 41 47 42 5E 51 05 78 04 5E 77 43 60 15 77 38 1E 01 00 38 16 6E 6F 54 1C 61 50 7F F7

...

I've tried to reset the pic, and reupload,,, same result.

I changed back to the 452 pic, and tried the same as above.  100% sucsess

I then uploaded seq V2 with full sucsess too..

Does the 4620 need more current than V2 (I really thing 7,5/1A should be enough)

Any hot tips?  This was very close...... I'll cry my pillow wet tonight..... but as allways...... things will turn out fine in the end...I'm 100% shure it will ;-)

Hope someone can assist me

[stryd_one]

The 4620 was ordered with PIC ID 0000000000000000

You need an IIC_MIDI module, and you will need to set the correct PIC ID  accordingly.

[mjproc]

Well from the wiki:http://www.midibox.org/dokuwiki/doku.php?id=mios_pic18f4620

Proposal for Beginners/Electronic Newbies:

* buy a preprogrammed PIC18F4620 from SmashTV or Mike with PIC ID 0000000000000000

* build the core module and test the MIDI In/Out of the board

* upload the PIC18F4620 version of MIOS via the MIDI Out port of the Core module

* build a MBHP_IIC_MIDI module and test it like explained at the MBHP_IIC_MIDI page

* select the ID 10 (both jumpers stuffed)

* upload the iic_midi_10.hex binary of the change_id package, this will change the PIC ID to 0000000000001000

* now the MIDI out stream is redirected to the MIDI Out port of the MBHP_IIC_MIDI module, you don’t need to use the MIDI Out port of the core module anymore (even for code uploads it’s not required anymore)

Is this not the proper way to do it? 

As my pic now has ID 0000000000000000 and I have no burner, how do I change the ID?

I honestly thought I could upload MIOS without the IIC attached... 

[stryd_one]

Yeh if you do it that way, you might need to enable the "don't use feedback from core" option I think... Because upload requests could get busted up by the UART bug.

But that doesn't explain why the core is sending upload requests... What's the LCD showing during all the different stages of this? The 4620 shouldn't draw more power but 7.5V is the minimum that I'd say was OK. What about if you disconnect the LTC?

[mjproc]

The display is blank.  I initially disconnected the ltc, but connected it again to better debug.  (I've tried to upload mios without ltc)

I have also tried to upload without feeedback from core.  same result, only fewer errormessages.

[TK.]

It could be a power related issue. Your PSU might be strong enough, but what about the 100nF bypass caps? Do you have a core module, where they are already available? If not, just add them at the bottom of the PCB

Best Regards, Thorsten.

[mjproc]

Both the pullup resistor and bypasscaps are implemented in my rev og core module.  I find it strange that the 452 pic behaves so nice and the 4620 pic beeing such an arse....

I suspect the 4620 bug is the root cause here, and I guess if I could make the pic id to be 0000000000001000.... I might be able to upload mios after bypassing the midiout on the core.

[TK.]

I don't think that changing the PIC ID will help here, because the EUSART bug affects the MIDI Out port, and not the In Port.

It seems like the PIC doesn't receive the MIDI data, accordingly it sends an upload request again.

Thats strange, especially because the same core module works ok with a PIC18F452

00000006215161 ms | Sysex message: F0 00 00 7E 40 00 01 F7

device ID is 00 - correct, so the bootloader should be addressed with incoming code blocks, sent to device ID 00 (default)

Could you please try different upload approaches to give me more input, what is going on here?

E.g., try it without feedback, try to upload a normal application w/o MIOS (program won't be executed... this is just an upload test)

Best Regards, Thorsten.

[mjproc]

Could you please try different upload approaches to give me more input, what is going on here?

E.g., try it without feedback, try to upload a normal application w/o MIOS (program won't be executed... this is just an upload test)

I've tried to force an upload, me inserting midi out just until it start sending data..... no mios

I tried to upload v3 app, but same error message (Error: Received unexpected Upload Request)

In desperation, I'm now trying to get the Roland serial driver going, and hopefullt be able to use the ltc module as path to upload mios

Doh!.... The driver is installed (W98) in my XP pc.... but I can't select the Roland serial as midi source in mios studio (nor in midiox)

Is the ltc method a path to follow?  Or will it lead to even less hair?

Ole P

[TK.]

I fear that the LTC module only increases the complexity (especially on today PCs), so continue with a normal MIDI interface.

I must say that I'm out of ideas! Who has programmed the PIC? Maybe it's a wrong bootloader or PIC ID?

Best Regards, Thorsten.

[TK.]

Ok, one idea: what happens when you send following MIDI message to the PIC (you can use the SysEx tool of MIDI-Ox):

F0 00 00 7E 40 00 02 00 00 F7

Best Regards, Thorsten.

[mjproc]

I sent the sysex, but can't find any sign of life,,, not a blip in lcd's nor leds, nor any change in Midi Monitor In. same sysex "Hal" message ;-) (I'm alive)

[TK.]

so, thats definitely not a PSU problem.

Unfortunately you forgot to answer my other question (who has programmed the PIC)

Best Regards, Thorsten.

[mjproc]

oh..... sorry.. I didn't see the post... The pic was programmed by Mike this week.  I'll send an email asking for those details now.

[TK.]

Hi Ole,

I made some experiments with the bootloader in order to get a feeling about what happens, when the wrong one is programmed into the PIC.

If the PIC18f452 bootloader is programmed, you wouldn't receive any MIDI data at all, only zeroes

The PIC18F4685 bootloader would work like the PIC18F4620 bootloader

So, it's very likely, that the problem is not caused by a wrong bootloader

I also checked my suggested SysEx sequence, and noticed, that an error won't be sent as expected. Problem is, that the core will be reset before the last byte (F7) is sent out.

However, following sequence should return an error response, could you please try it?

f0 00 00 7e 40 00 02 7f 00 00 01 11 22 33 44 55 66 77 00 00 00 00 f7

Best Regards, Thorsten.

[mjproc]

Got a reply from Mike:

"I checked the hexfile for the bootloader for the PIC 18F4620. It is called bootloader V1_2a."

I tried to send the sysex, but no response received back.  Only:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT             

00000767  1  --    F0  Buffer:    8 Bytes  System Exclusive     

SYSX: F0 00 00 7E 40 00 01 F7

..

..

..

  Many thanks for taking time to help me out!

[TK.]

thats strange, because there is no "bootloader V1_2a" file released, only bootloader_v1_2a_pic18f4620.hex and bootloader_v1_2b_pic18f4620.hex, whereas for PIC18F4620, there is no functional change in both versions

I will contact Mike, maybe it is a wrong version

Nevertheless it could make sense to send me the PIC for further analysis. I could read out the bootloader and compare it with the official version. And if it is identical, I could check it on my core module. Since there are not so many users who have tried the PIC18F4620 yet, I cannot exclude that a certain chip revision doesn't work properly

Best Regards, Thorsten.

[monokinetic]

Hi, just to add my 2 Euro cents worth:

2 weeks ago I think I ran into exactly the same problem. I bought my new 18F4620 PIC from Mike pre-flashed. But because I've been MIDIboxing (yes its a verb now!!) for a while now I bought a PIC burner PCB, just in case....

With PIC 18F452 my MBSEq 2 was running fine, I regularly reflashed the box with MIDIO128 app, something I compiled myself and the shift register tester etc etc. When I put my preflashed PIC18F4620 from mike in exactly the same box (yes I added the extra resistor on the IIC bus before you ask!) I couldnt manage to get MIOS studio or MIDIOX to upload the software. MIOS studio gave me rpecisely the same error message as mjproc mentioned in their 1st post "unexpected upload request". The box constantly sent out the upload request but never seemed to give the first repsonse so MIOS studio abborted the upload. If I turned off smart feedback from the core the whole upload was sent but it never seemed to be programmed into the chip ie it still just sent out the upload request every 2 seconds.

As I mentioned in this message:

http://www.midibox.org/forum/index.php?topic=8673.msg61123#msg61123

after almost 1 week trying to upload MIOS and the app I decided to build my PIC burner. This worked perfectly first time, I then read in the preflashed PIC versus the correct bootloader hex file and P18 reported over 500 errors in the program and (from memory) 8 errors in the device id. I reflashed the PIC with the bootloader, put it into the same hardware, and voila, MIOS studio uploaded the software first time :D

I then used the change ID app to set my device ID to work with the IIC Midi out put, it worked fine. The only problem I have at the moment seems to be connected to the IIC midi, I will save details of this for another post once I have investigated further (need to build my COREV3 PCB and do some fault finding!)

My point is that I think we should double check with Mike re: testing one of his pre-burnt PICs because if I hadn't bought the PICBurner PCB, I would have been totally stuck. Especially as in a few places it is recommended for newbies to buy their PIC preflashed......

I hope you dont think I'm hijacking the thread, but I think there are enough similarities here to investigate further.

Best

Dave mK

[stryd_one]

Hmmmm.... Are you guys getting these shipped through Customs perhaps?

[mjproc]

Fyi:  I've sent my pic to TK for debugging.  I guess we can put this thread on hold until TK solves the puzzle.

[TK.]

Thanks for the input, Dave! Ole has already informed me about your posting, your observations are very helpful! Especially because you've encountered exactly the same problem!

It seems that Mike has done everything correctly. He sent me a .hex readout of a programmed PIC18F4620, and it matches 1:1. So, I definitely need Ole's PIC in order to continue with the analysis.

Are you guys getting these shipped through Customs perhaps?

thats an interesting speculation, as flash memories are sensitive against X-rays. But with todays scanners this shouldn't be an issue anymore, otherwise 1000 of people would lost their MP3 collection when they are scanned at the airport... however, nothing can be excluded.

Best Regards, Thorsten.

[monokinetic]

TK: Thanks for your vigilence, as ever! I have a feeling I read the PIC into P18 before I flashed, I can PM it if you like?

STRYD: I'm in Prague, the Czech Republic - Mike Germany somewhere. I don't imagine there would be too many security checks.

In fact, they don't check at the Czech borders much :)

[sorry couldn't resist it!]

d

[TK.]

TK: Thanks for your vigilence, as ever! I have a feeling I read the PIC into P18 before I flashed, I can PM it if you like?

Yes, please! This allows me to compare the contents between both failing PICs - great that you thought about this! :)

Best Regards, Thorsten.

[TK.]

Ok, I received the PIC today and noticed, that a small portion of the bootloader was not programmed into the PIC:

:10024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE
:10025000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAE
:10026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E
:10027000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E
[/code]
Thats a 64 byte range between 0x240 and 0x27f. This explains the strange behaviour (upload request, but programming not possible)
After reprogramming the PIC (I tried v1.2a and v1.2b) the chip works ok.
I also tried the protection mechanisms - uploading a wrong MIOS Version (e.g. 1.8 ) does not overwrite this flash area, this is good!
So far I know, the P18 software programs 64 byte blocks, so it could be that one block was missed.
But it could also be, that Mike's .hex file was incomplete.
Therfore: @Monokinetic - it would be very helpful to get your .hex file!
Best Regards, Thorsten.

[mjproc]

Great!  I really hoped there was something bogus with the bootloader... and not my head (again)