 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 11 of 28   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Was out today but will try to look at it tomorrow. I have the code typed in but it's untested! BTW, I think SetMode with 1f, 6 i.e. 111110 takes the TAP controller to Reset (11111) then to Idle (the final 0) if that helps. The pic here is convenient rather than a PDF (for me). John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@JohnS As far as I can make out, SetMode is working as I can check Status ok, read device id code ok and erase chip also works. All the pseudo code functions appear to work i.e data in and data out seem to be correct until I try to use the xferinstruction pseudo code. Thanks for the section on the TAP, I'll see if it make any more sense with the PDF files I already have. It would be nice to know if anyone has got xferinstruction to work and what language/format it is done in. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Have done a bit of testing. When I use XferInstruction I get back (hex): c004c008 after using EJTAGBOOT 4004c008 otherwise They seem to make sense as the top bit that is only set after EJTAGBOOT is the ROCC bit which confirms a reset has just occurred. What value(s) do you see? So far so good, but I'm sending what I thought was sane (?!) MIPS32 ASM (as hex) and after that I read the FASTDATA register. But I get PrAcc as 0 instead of 1. I suppose this means either my ASM is bad or my code to get Fastdata is bad. More testing needed... edit: or my typing is rubbish - I dropped a 0. Now it "works" but I get all 1s John |
||||
| JTR0701 Regular Member  Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Not sure why you are testing bit 14 for the prACC bit when it is actually bit-18 (unless you are assembling the bits in reverse order where bit-18 would became bit-14. However I see no reason why you would be doing that and I see no code that shows what you are doing. Unfortunately you cut out too much code for me to be able to give a fully helpful answer.) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
The TDO "dataout$" has its LSB on the right (normal binary) and so need to test bit 18, but this is represented as a string which counts from the left which is bit 14. Did you open the zip file for the rest of the code? I think there should be enough to go by as what was cut out was the code relating to downloading the PE loader, data block and flash programming etc. The block of code shown on the screen is just the XferInstruction routine. David M. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Hi David, I went over the code in the zip file numerous times. It does not include the low level primitives I needed to verify why the bits may be reversed. Now you have explained it, it makes sense. Seems to me you may have missed that the first data bit is clocked out on the last bit of the TMS header, not the first bit of the data in. You need to "remember" this bit and carry it over. Then the whole 32-bits of data that clocked out as the instruction is clocked in, need to be shifted to the left (ends up shifted right in your string) with the carry over bit from the header put in bit-0 (string - bit-31) and the previous bit-31 (bit-0) discarded. (Just when you thought this was complicated enough...) Last time I seen your low level primitives there was no provision for this to happen so I think it is a fair bet that is a good place to look at next. -Jim |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
David, Just realised that I should say the (hex) values I posted are what my code gets. You should see the same values, but what do you get? John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@Jim That gives me something to chew over. I suspected something like a "carry over" bit (rightly of wrongly) because the data clocked out is displaced 1 bit left. Is this normal? Must have a closer look at the timing charts again. I am just a bit puzzled because the XferData works quite happily with the DeviceID code read and display. @JohnS My XferInstruction routine is locking up on the first XferData 0004c000. The 32 bit word clocked out is 0004c000 shifted left one bit. I think I need to display data in vs data out and look more closely at the number of bits and bit patterns. The MaxiMite text is not the easiest for ageing eyes to see clearly. I'll be back.... David M. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
David, sorry! The "missing code" is in the zip file. When I double clicked the .BAS file it opened in the VB6 IDE. Great I thought, syntax highlighting, I was expecting it to open in textpad with no such luxuries. The thing is, as soon as it opened in the VB6 IDE, all the subs and functions were separated from the main guts of the code and I didn't see them.  Forgot about that...
As it turns out your code is far more advanced than what I had seen previously and it appears to me that you are correctly picking up the first TDO on the last TMS clock so scrub that idea. One thing I did notice is a nasty in this bit of code: '========= Sub setmode(st$) Local x For x = 6 To 1 Step - 1 Pin(pgd) = 0 'TDI Pulse clk, .01 Pin(pgd) = Val(Mid$(st$,x,1)) 'TMS Pulse clk, .01 Pulse clk, .01 Pulse clk, .01 Next x End Sub '======== Notice that it does not set the pgd pin as an input for the TDO like your "clock" stub does. Doubt this is the problem at hand here but it is still not correct none the less. I cannot see a prime suspect in why the readback is shifted one bit. May get a chance to look at it in more depth later. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
My current version is as you suggest - I tried it last night out of desperation but it made no difference but left it with the pgd as input in the appropriate place. Now I'm starting to dream about the B thing! Glad you found the rest of the code. If I had left in all the flash programme and verify etc. it would have been considerably more cluttered. Interesting to note that regardless of what code I feed in in place of 0004c000, the resultant dataout$ is always the 0004c000 left shifted 1 bit. Time to look up the bits of the control register to see what they are really meant to be. biik ! David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I'm hunting around the code and will post any randomish thoughts. I see in clock that you read in tdo later than I do, though I have a comment to remind me that mine may be wrong (I hate that Mchp datasheet). I have (in pseudo C code): /* swap next two? */ tdo = pin clk = 1 clk = 0 return If wrong, and I don't know it is or isn't, I don't see how that could cause a shift or why it wouldn't cause lots of other trouble. I try to leave that "pin" as an input as I figured my code will run very slowly across USB so any clashes would last ages. The reason I got to clock was that I was wondering if there's an unread bit lying around. The above wouldn't account for one as far as I can see. Not currently relevant but I don't think your read_memory is right - it doesn't look to write into the fastdata register at ff200000 (mine also doesn't work so take my thought with a sack of salt!) John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
@John I can't see how the clock can be the cause (but that just means I can't see it - it just might though). I had a look at the ECR and the PrAcc etc are in the right place, so a body is still none the wiser. Another sleepless night? It's a mystery because deviceID also uses 32 bit xferdata and works ok. So....? David M. |
||||
| JTR0701 Regular Member Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Right, you need to swap the top two around. Correct and correct. David is not writing the prACC bit so the xferfastdata sub is currently borked. However it is not being used yet so that is not the current issue. However the code will need to be fixed to write the prACC bit as per figure 6-9 in the prog specs. Good catch! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks, Jim. I've swapped the lines (more than once) and the odd thing is it makes no difference, which at packets over USB speeds (slows!) surprises me. The XferFastData looks wrong for an extra reason as it doesn't check the PrAcc that comes in to make sure it's 1. But I agree it's not even being used yet so cannot be relevant to the XferInstruction problem. It's got me stumped I think. A small oddity: in function hextobin$ the local h$ is not explicitly set to an empty string. I didn't realise MMBasic auto-initialises string variables (as I suppose it must be doing). John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I didn't think the xferfastdata was correct, but that has been the least of my problems, but it is now on my list as a definite. Just need to solve the current problem and find an elusive round tuit. In three weeks the wife and I will be in Holland/UK for 6 weeks. I'll have the laptop and the hotels have wifi so if it isn't done and dusted by then I can keep in touch. Meanwhile, back to the scratch pad. (the balding spot on the head) David M. |
||||
| JohnL Senior Member  Joined: 10/01/2014 Location: SeychellesPosts: 128 |
Pickit 3 is down to US$20. Is it genuine or not? IT WORKS PERFECTLY so who cares. 
http://www.banggood.com/Pickit3-Pickit-3-Kit3-Emulator-Progr ammers-Programmer-p-88947.html
|
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Reading about the effort these people are making, Microchip should get ashamed! They said they will give a helping hand... Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Help from Microchip would be good! Not sure what would be most useful (hardware LOL or even a better PDF about this stuff). Meanwhile, I got a ReadMemory function working :) Also have the PE loading and it will read me one word. Then it seems dead :( It doesn't always even manage one, so something's not right! Takes about 90 secs to load the PE and start it running. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Hi John, I wonder if I have been jumping the gun by trying to verify memory too soon. I thought that I should be able to do a verify after an erase but perhaps I need to properly enter serial execution mode first? I imagined it was only needed for programming but is it also required for reading? Something to try later today. David M. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I haven't yet tried an erase as I fancied ReadMemory and its ilk first. To get that working I do EnterSerialExecutionMode and then set the BMX regs and finally ReadMemory seems OK. SetBMX is: /* step 1: init BMXCON (at 0xbf882000) to 0x1f0040 */ XferInstruction(0x3c04bf88); /* lui a0,0xbf88 */ XferInstruction(0x34842000); /* ori a0,0x2000 */ XferInstruction(0x3c05001f); /* lui a1,0x1f */ XferInstruction(0x34a50040); /* ori a1,0x40 */ XferInstruction(0xac850000); /* sw a1,(a0) */ /* step 2: init BMXDKPBA (at 0xbf882010) to 0x800 */ XferInstruction(0x34050800); /* li a1,0x800 */ XferInstruction(0xac850010); /* sw a1,16(a0) */ /* step 3: init BMXDUDBA & BMXDUPBA to value of BMXDRMSZ */ XferInstruction(0x8C850040); /* lw a1,64(a0) */ XferInstruction(0xac850020); /* sw a1,32(a0) */ XferInstruction(0xac850030); /* sw a1,48(a0) */ ReadMemory arranges to call that if not yet done, then: XferInstruction(0x3c13ff20); // lui s3,0xff20 (==fastdata) XferInstruction(0x3c080000 | (addr >> 16)); // lui t0,(high addr) XferInstruction(0x35080000 | (addr & 0xffff)); // ori t0,(low addr) XferInstruction(0x8d090000); // lw t1,(t0) XferInstruction(0xae690000); // sw t1,(s3) XferInstruction(0x0); // nop (needed?) SendCommand(ETAP_FASTDATA, 5); return XferFastData(0); John |
||||
| Page 11 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
