 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. |
Forum Index : Microcontroller and PC projects : simplest 32MX150 ICSP
  Page 12 of 28   |
|||||
| Author | Message | ||||
| MOBI Guru  Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Erase is simple as it can be done before entering serial exec mode. I haven't got to verify yet as I am not sure of my fastdata function. Maybe I've found a bug in Microchip's docs. PDF DS60001145N-page 22 - Figure 10-1. last line ..... SendCommand (MCHP_SW_ETAP)
I wonder if this should read SendCommand (MTAP_SW_ETAP
With that change, my verify section no longer locks up i.e. no 1 bit shift left. Meanwhile. I analyse your code. We'll beat this thing yet! David M. |
||||
| JTR0701 Regular Member  Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Yeap! I reckon that's it. 
It is the program specs and the fact that there is not a "define" for "MCHP_SW_ETAP" so I guess it results a default of '0' being sent. This throws out the ETAP state machine and as a result it "uses" an extra clock to re-sync. I'm confident that is the cause and you can move on now. 
|
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
That'll be it! My code already has the correct line (i.e. is not the same as the Mchp doc) so I must have stuck in the obvious code without even noticing the doc is wrong. My code is now at the stage where it nearly always loads a PE that can do one PE command. I'm puzzled why it fails then (i.e. won't to do more than one). Very odd. BTW, I don't know that the BMX code I posted is needed but ReadMemory didn't work till I added that code. The doc is little help. I'm running very short of "spare" time for this. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
When I wrote the code for xferinstruction and the like, I did quite a bit of cut and paste as I wasn't up on TAP functions, so it is hardly surprising that I didn't pick up on the microchip misprint. The TAP is quite logical when one looks at it closely. I wonder if we should inform Microchip - or perhaps someone already has? Probably in an errata somewhere? Don't know why yours balks after one pass - perhaps I'll find out as I get further along the road. Fun times ahead?? David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I'll have a go at reporting it. I've reported a longish list of PIC32 ones in the past so maybe they'll actually take note. (A lot of their docs are good but when they're lacking they can really leave me puzzled.) There's another error in the doc I meant to report so will add it (if I can recall it!) I think the PE single-command thing must be my code but it's in the simple stuff with few lines of code - very unlike the stuff to load the loader & PE, which generally works. Well, seems to - the error detection is roughly nil :( Aha. I'll try checksum/crc. That doc mistake is Sod's Law: if I'd followed it then gcc would've reported an error, forcing me to correct it, but MMBasic can't really spot such things. Oh - would MMEdit help? Could/does it report suspicious variables (unset, used only once, etc)? BTW, I converted the PE hex (RIPE_11_000301.hex) into a rather long list of constants in a C array. If it's any use to you I can upload it, but I suspect it'd not be the best thing for Basic. I also have the hex as a bin file (memory image, none of that ascii etc stuff) if that's any use. I can reformat if you wish. For the C array I used: ihex2bin RIPE_11_000301.hex | hexdump -v -e '" "' -e '8/4 "0x%08.8x, "' -e '"\n"' John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I'll have the HEX file on the SD card on the MM and it is quite easy read and format using string variables as I have done thus far. It mightn't be the fastest but at least it is relatively easy to follow. Well....that's the plan. But if you want to upload your array at least I can see how it fits. Meanwhile, I have a little refining to do to XferFastData to test the PrAcc bit. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
OK, try this. 2014-07-03_085806_PE.zip John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@JohnS Thanks for the PE array. Filed away until I get this bit working. I have added a bit test for PrAcc (obtained from TDO after third TMS header block) but can't get it to output a 1. The notes state that if PrAcc is not a "1" then the whole process has to be repeated. Logic would suggest they mean the full xferfastdata code or the TAP machine would end up out of whack? David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I have had odd instances of the same trouble and have a TODO to change the logic to retry in a sane(ish) manner. XferFastData is used a lot with the PE and (except for the occasional thing I've just mentioned) works fine to load it, start it and then the first command. That's a lot of XferFastDatas. So I'm really puzzled why my PE then fails. Getting the state back to retry the XferFastData's TMS header is easy enough but it concerns me that the PrAcc may not set at all. So I'd need to completely restart from... well, where? Reloading the PE is what I currently have tried and it seems to work but it's another about 90 seconds (as I'm using USB)! Anyway, more bug hunting needed. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Fixed it! I was not doing SendCommand(ETAP_FASTDATA) enough. Need to play with chip erase & programming at some point soonish. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I think I must not be understanding this fastdata function. I can't understand why in xferInstruction we check for PrAcc as part of the control word (which seems to work ok) but then again from TDO in the last clock of TMS header of xferfastdata, which for me shows a "0" where it should be "1"? David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
In XferInstruction, ETAP_CONTROL selects an entire register (32 bits). With ETAP_FASTDATA, a single bit (PrAcc) and the data register are selected (33 bits) and there's a somewhat odd (to me) way of clocking all 33 bits in. There must be some sort of interlock of that stuff inside the EJTAG unit in the PIC32 chip so that data from the outside (the programming wires from our code heading to/from the PIC32) and the data inside the PIC32 are sync'ed. That latter data is being created/consumed by instructions running in the PIC32 core. Those instrs come from XferInstruction or are such as the running PE. (The details are somewhat spelled out in the MIPS EJTAG doc but actually you can figure out the kind of things just by thinking how the handshaking has to work.) Possibly you could instead use ETAP_CONTROL then check the PrAcc and then use ETAP_FASTDATA and read the data, ignoring the PrAcc bit. Hang on a bit and I'll mess with my code. I don't know why you'd see a 0 when I see a 1 (not quite 100% of the time but nearly). Maybe you have another variable that's not right, a typo or the like? Will MMEdit help find it, such as the cross-ref I think it can output? edit: I tried a variant of XferFastData and it part works but only part. When the PE runs and I send a command the output (GetResponse etc) is missing at least the low 16 bits of the code (weird). What I did (it's a hybrid of XferInstruction and XferData): SendCommand(ETAP_CONTROL, 5);
do { cv = XferData(EJTAG_CTL_CHECK, 32); } while (!(cv & EJTAG_CONTROL_PRACC)); SendCommand(ETAP_DATA, 5); ret = XferData(data, 32); SendCommand(ETAP_FASTDATA, 5); return ret; I don't know if it's genuinely running the PE or not, however. Probably not. I think what the above fails to do is shift a 0 through PrAcc in order to make the handshaking work. If you've seen the JTAG state transition diagram, I think it (the ones I've seen) leaves out a lot more things that happen on some transitions. Something like on a TMS footer or header a transfer occurs or a bit position is reset. Etc. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I've looked for typos till I'm seeing double - only found one or two but that doesn't mean there still isn't one. Wouldn't be the first time I've read and re-read a programme and not seen an obvious error. Would you believe, I've never used MMedit. Maybe this is the first time I should be using it? A bit more brain ache to go yet I suspect. I have to brave the cold and dark and switch the generator off. My 500watt wind turbine did in a bearing, poled and cooked last night. And of course, we didn't get much sun today so the batteries are down a bit. Don't know if it is worth fixing the turbine, just put in a few extra solar panels instead. The turbine never did do too much anyway. Just like its big brothers. As a consequence, didn't have much spare power to play electronics with. Sort it tomorrow. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I never used MMedit either (wasn't writing MMBasic!) until very recently and then tried it under Linux. It's a work in progress there! Still, kicked it around a bit. Under Windows it'll be far better I believe and looks easy enough to use. Give it a go - and early on try that version of your code you had with MCHP_SW_ETAP and see if it does pick up the sole use of it. That way you'll see if it picks such things up. (Sorry, haven't tried it but as I say I really don't write MMBasic other than very rarely.) I suspect you don't need a 'mite connected but may need a COM port so it runs. Don't know. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@JohnS I did a text scan of the pic32 documentation and couldn't find any reference to MCHP_SW_ETAP other than the misprint. Anyway, I can't think of any reason why that command would be used - don't make sense. In the xferfastdata command, have you tried testing the state of PrAcc after the third TMS header clock. Just curious if you get a 1 or a 0. No matter what I try, I can't get a 1. This evening I'll have a tinker and test the value of all variables as I use them to try and pick up typos. Will be a slow job but it might reveal the culprit. I's a pity that MMbasic will accept variables without being declared. A throw back from early Basic days. (Blame Bill Gates). Anyway, on a brighter side, I replaced the bearings on the wind generator and it looks to be electrically and mechanically OK. Now "just" re-fit to the tower and try it out. I suspect that the "cooked" look resulted from water getting in through the shattered bearing and getting a little rusty. Fingers crossed. ====================== We will be in UK (Manchester) for two weeks in August. PS I missed your post with the edited command routine - must have come in after I read the previous. I'll see if I can replicate it. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Ooh, I'm not exactly close to there (abbrev: Mcr) so might be able to drop over by train, depending if you/I have time etc. If you get a chance Mcr has lots of attractions including the Museum of Science and Industry - which has "Baby" a very early computer. I do see PrAcc, in fact rely on it really, until I get some proper error recovery in. (My actual code: omits the 1st 5 lines of the below, tests the PrAcc and if 1 carries on, else error recovery.) I made another variant - and this one seems to work. The idea is select ETAP_CONTOL and look for the bit, as XferInstruction does, then select ETAP_FASTDATA and shift the bits without looking at PrAcc. (It's ever so slow via USB!) SendCommand(ETAP_CONTROL, 5);
do { cv = XferData(EJTAG_CTL_CHECK, 32); } while (!(cv & EJTAG_CONTROL_PRACC)); SendCommand(ETAP_FASTDATA, 5); PrAcc = SetMode(1, 3) & 1; ret = icsp2w(0, 0); // input PrAcc of 0 while (len--) { bit <<= 1; ret |= icsp2w(data & 1, 0) ? bit : 0; data >>= 1; } icsp2w(data & 1, 1); // send data MSB with TMS 1 SetMode(1, 2); // send TMS footer 10 return ret; My SetMode returns the TDO values, shifted as they arrive, last one in LSb. The above shifts 33 bits: PrAcc, 31 in the loop, 1 after that. Function icsp2w(tdi, tms) is like your clock. Variable "bit" starts as 1. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Thanks John, gives me something to chew over and experiment. What town/city are you near - so I can check on our old road map book from our '96 trip to UK. Was also there in 2010 for a Mcr wedding (niece). Might hire a car whilst there this time. I had a look at "baby" - looks like some of the gear I used to work on in an earlier life. Will try and have a look at the real thing whilst there. I have a bit to do over the next few days so I might be absent from the forum for a bit. We'll see. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
There must be stuff about Alan Turing, as well, as he was at Mcr Uni after the war / Bletchley Park. Mcr is the "home" of graphene, too. I'm fairly close to Leeds, which has good links to Mcr. Just some hills (the Pennines) and dales in between. No worries on the code, I'm out of time myself for about a week but will try to keep up with messages. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@JohnS I wonder, have you tried to flash some non code protected code to the uMite using PICKit3 and reading it back with your code, or are you already able to write and verify? (will be out of mobile internet range for about 48hours. No point in even taking the laptop. Will check messages when we get home maybe tomorrow night. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I read out some already-programmed flash and it looked right. Didn't have time to write any code to erase or program. John |
||||
| Page 12 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
