QG8 & P&E Debugger + Cyclone Pro + IIC

[admin]

I've got a QG8 and I'm trying to get data out of a 24LC512 EEPROM via the IIC bus interface. I send a start condition, the device code + r/w bit set, then 2 address bytes, another start condition, another device address + r/w bit clear, then turn off the TX bit and do a dummy read to get the clock going for the 1st byte. I then wait for the TCF bit to set and read the IIC data register, over & over until I have all the data I need from the EE. It all works fine now, but debugging it was a real bitch. It seems that when the debugger's Memory window is displaying addresses that cover the contents of the IIC registers (specifically the IIDR at $34), then whenever the debugger stops it reads the IICS and IIDR for display, which it's supposed to do. But this screws up the IIC transfer because the chip takes the debugger's IIDR read as its trigger to clock in the next byte. I've never experienced any problem of this sort before, and I've always been under the assumption that reads in DeBug mode do not behave the same as reads from user code, i.e., they were sort of invisible to the chip's peripheral systems. Have I been under an incorrect assumption all this time or am I looking at a bug in the chip?

Message Edited by Wingsy on 2008-03-21 04:21 PM

[admin]

I meant to mention in my previous post....

The data sheet says this about the TCF bit, "The TCF bit is cleared by
reading the IICD register in receive mode or writing to the IICD in transmit mode." That ain't so. To clear the TCF bit in receive mode (not tested this in Tx mode) you must set the IICIF bit even if interrupts are not enabled.

(Try troubleshooting THAT one when the debugger is reading the data register every time you stop or single-step!)

[JimDon]

From my dealings with the BDM interface, it just reads memory like anyone else, so I would say you have an incorrect assumption.

What you should do in  a case like this is not look at the registers and check "no memory access while running" and perhaps un-check "refresh memory when halting". These are found in the "Debug memory map" dialog.

What I have done is set a break point just before and one just past the while loop that tests the bit. If it never gets there, then something was wrong.

Or you could have searched the forum and found this.
Or this;
I'd be interested to hear if this looks correct to you. I have not had a chance to test it.

[admin]

Right, and thanks for your input Jim. I assumed my assumption was incorrect, since it does behave like a normal read. Would have thought I would have stumbled on that before now. Anyway, I can't find the "Debug memory map" dialog anywhere and the only thing I do see about memory access while debugging is a setting for the period of memory display updates (under the "Memory:Modeeriodical" item). I'll just insure that I'm not displaying memory in the register space from here on.

The 1st link you supplied doesn't refer to the QG8, and the 2nd one does but utilizes interrupts to perform the I/O. An interrupt driven IIC transfer doesn't experience the problem I was having since the IICIF flag is reset in the IRQ routine. If one relies solely on the TCF flag in a non-interrupt driven I/O, you'll fail unless you also clear the IICIF bit... even though interrupts are not enabled. This is not true for a GT32A, even though the data sheet for both a 32 and a QG8 are almost word for word in the IIC chapter. I'm using the same code in a 32A and the only difference is to reset the IICIF in the QG8 to make it work. In my QG8 I'm using interrupts for the IIC I/O most of the time and they work just dandy, but I started having problems when I needed to read the EEPROM chip in some code loaded into low RAM, without interrupts. (My code is reprogramming the flash from data read from the EEPROM chip.)

I still believe that the QG8 has a bug in its IIC functions, specifically the characteristics of the TCF bit. At least now I know that BDM reads aren't invisible. Got to remember that.

And by the way, I couldn't tell you if that code looked ok. I have lotsa rust all over my c. I can barely read it. What I do I do in assembly.

[JimDon]

Your right, that first example was not HCS sorry about that.

For what it's worth, the "Debugging Memory Map ..." is in True-Time (Hiwave) under the entry that is for the BDM you are using (it changes its name depending on the plug-in for your BDM) e.g. MultiLinkCyclone for a P&E BDM. This is on the top menu 4th one from the left, not on a right click menu. Select the item labeled FLASH then click "Modify/Details" This is where you will find the two check boxes I mentioned.

You will also find "Disable ISR's while stepping" on this menu which is quite handy.

For what it's worth, it would appear that AN3291 documents this, and it would appear that you should be waiting for IICIF and clearing it as a matter of course, not TCF . Ya, I know "Now you tell me". I guess in fairness to Freescale, they did publish an app note on it.

Code:

(from AN3291)
void IIC_write_byte(word addr, byte data){Address = addr; // load address;temp = (Addr_H & 0x07) << 1;IIC1C_TXAK = 0; // RX/TX = 1; MS/SL = 1; TXAK = 0;IIC1C |= 0x30; // And generate START condition;

//-------start of transmit first byte to IIC bus-----IIC1D = IIC_SLAVE | temp; // Address the slave and set up for master transmit;while (!IIC1S_IICIF); // wait until IBIF;IIC1S_IICIF=1; // clear the interrupt event flag;
while(IIC1S_RXAK); // check for RXAK;//-----Slave ACK occurred------------IIC1D = Addr_L; // Send low byte of the word address;while (!IIC1S_IICIF); // wait until IBIF;IIC1S_IICIF=1; // clear the interrupt event flag;while(IIC1S_RXAK); // check for RXAK;//-----Slave ACK occurred------------IIC1D = data;while (!IIC1S_IICIF); // wait until IBIF;IIC1S_IICIF=1; // clear the interrupt event flag;while(IIC1S_RXAK); // check for RXAK;//-----Slave ACK occurred------------IIC1S_IICIF=1; // clear the interrupt event flag;IIC1C_MST = 0; // generate STOP condition;}

 

Message Edited by JimDon on 2008-03-21 07:43 PM

[admin]

Oh yeah, NOW ya tell me!
I looked for all the app notes for the QG8 and 3291 wasn't listed. Guess I should have looked for IIC app notes. Anyway, it's weird, cause 3291 is a c implementation of my IIC IRQ routines, except where he uses a numerical value in a flag byte to direct his IRQ state machine, I did it with flag bits in a byte. Funny how we did it the same way, almost exactly.

And under my "MultilinkCyclonePro" menu, I have no "Flash" item. I'm using version 6.1 build 6124. Am I that far behind in updates?

[JimDon]

Well, the spec sheet was not clear.
It did say for IICIF "This bit must be cleared by software, by writing a one to it in the interrupt routine" which could be taken to mean only if you are using interrupts, or could be taken to mean do it elsewhere (not in the interrupt routine) if not using interrupts. They should have left off "in the interrupt routine".

Your code is the same because I guess there is one correct way to do it.

I have build 7285, but yours should be the same.

Under the "MultilinkCyclonePro" menu do you have an item "Debugging Memory Map ..." ???

This leads to a dialog that has a list of memory areas.  I'm sorry, on your processor it will not be labeled flash, it will be labeled "Default Memory block 3" and have a range 0000E000-0000FFFF.

Highlight the block and click the button "Modify/Details".
This is where those check boxes are.

[admin]

Under the "MultilinkCyclonePro" menu I have:
Load...
Reset
--------
Command Files
--------
Device:9S08QG8 >>
Communication...
--------
P&E Micro Hardware Documentation >>
Advanced Programming/Debug Options...
Start Expert Mode Programmer...
--------
Write Register Files...
--------
Trigger Module Settings...
Bus Trace


I'm going to insure that I'm not displaying any peripheral registers while stepping or stopping my code so even without that missing menu I'll be OK with what I do have. Still it's strange why I don't have it.

I think I'll be posting another subject soon if I can't get my flash bulk erase code to work. It does on the 32A but not the QG8...again.

[JimDon]

Ok, thats because you are using CW 5.1, not CW 6.1.
I did not realize that HIwave had changed that much.
For whats it's worth, 5.1 and 6.1 can both be installed and work if you want to try out 6.1.