3

Right now I'm trying to implement the flash programming specification for PIC32MX. I'm working with a PIC32MX512L and a PIC32MX512H. The PIC32MX512L must eventually transfer a program to the two wires PGEC2 and PGED2 of the PIC32MX512H.

Right now I'm trying to execute the check device operation. As specified, I'm entering the programming mode by MCLR-juggling and executing SetMode (6b011111) on the TMS clock while the TDI clock stays low. The TAP controller replies with zeroes (every TDO is low).

After that I must execute SendCommand( MTAP_SW_MTAP ) to select the MTAP controller. The sequence to be shifted is 

(header) 01 01 00 00_ | (data) 00 00 10 00 00 | (most sign. bit) 01 | (footer) 01 00

The first bit of each pairs is the TDI and the second -- TMS. I write TDI on the first clock, TMS on the second clock and read TDO during the third and the fourth clock. This sequence is feeded from the left to the right. Shifted bits hold their value during each clock fall.

The issue

After shifting the first 4 pairs, the TDO line goes on the fourth pair high (on the third clock) and low at the end of that 4-phase part (on the fourth clock). I've marked this spot with an underscore in the sequence above. After that the controller ignores any further commands. On the next SendCommand( MTAP_COMMAND ), the TDO stays low and later on for XferData( MCHP_STATUS ) TDO still stays low, no matter how often I send the command.

I've done a small screenshot from my oscilloscope. The blue line is the clock, the green one is the data. The hop on the right is what I mean.

https://i.stack.imgur.com/MSGZh.png

The question

Does anyone know what the TAP controller is trying to tell me with that TDO high on the fourth phase?

Thank you in advance!

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56
indmg
  • 92
  • 6
  • I've found a few mistakes in my implementation so far. Now I still don't know whether I understand the specification completely right: according to the fig.6-4, a command 5h0x07 should be written. The LSb piece shows that it writes those five bits. After that the MSb is being written. I understood that the MSb has to be repeated. In the contrary to that, in fig.6-6, XferData writes 31 bits in LSb and MSb. I didn't see that. My second mistake was that in 6-6 TDO output starts already with the last header bit while in 6-4 it starts to write TDO with the first command bit. – indmg Apr 09 '13 at 09:35
  • Thank you very much for fixing up my post, Martin. I can now erase the device successfully and once I've managed to flash it, I'll post my experiences here as a complete answer. :) – indmg Apr 10 '13 at 06:20

1 Answers1

0

Well, I've fixed it. Generally the last TDO of the prologue is the first least significant bit of the output. For SendCommand it has no meaning, but for XferData and XferFastData it is important.

For XferFastData it is the PrAacc bit according to the spec. If the bit is zero, you should repeat the whole operation. But beware: the MCU implementation doesn't follow the spec. If you really restart the whole operation for FastData if PrAcc is zero, it won't work. Instead just ignore the bit and proceed writing. I've found it out eventually by trial and error and by comparing my XferFastData implementation against pic32prog.

indmg
  • 92
  • 6