Sticky BugList for CW 5.1 code generator? (MC9S08QG8)

[WillDesignForFo]

Maybe this has been done before, but since I'm new...

Now that I earned my scars from my first CodeWarrior project, I was wondering if anyone has a list of bugs for the code that comes out of the code generator from CodeWarrior 5.1.

Now before all of you say, "It's fixed in the next release", let me say that if so, then CW should support the code in their Special Edition they ship with new DEMO boards, or they should start shipping 6.x with their DEMO boards now.  As a minimum, they could include an errata sheet with the CD that says "the following beans don't work for beans".  I understand that their marketing model does not supply all of the possible code generator beans, and that's fine.  They need to eat too.  But the code they do generate should be supported.

So after that, here's what I learned the hard way (from the code I generated for MC9S08QG8):

1.  Serial Port code:  (AsynchroSerial bean).  At least for the baud rate I wanted (4800), the code generator calculated the wrong value to load into SCIBD (the actual baud rate).  With a bus divider of 1, the PE GUI calculated that SCIBD = 0x6D.  This is incorrect.  The actual value should be 0x68, and it is off enough that the communication doesn't work.  I lost a lot of time because I thought it was my bug.  I found it by studying the DEMO_MC9S08QG8 source code that sets it to 0x68, and then it all worked fine.  I also found it a bit strange that the DEMO apps apparently don't use the code generators at all, but were coded from scratch just to show off the possible applications.

2.  IIC (or I2C) code:  (EI2C1_SW_I2C bean). I found that it had most of the routines I thought I needed to implement the protocol.  I realized that to use it, I would need to do the STOP manually, which is fine.  After studying the code, I immediately realized that they were missing the mark on the IIC protocol.  I've written C for IIC and SPI devices before and after studying the code, I was sure nobody tested this code on a real device.

The first problem is that there is no provision for the Address in the routines.  Now what can be confusing is that there are two addresses.  The first address is the Device Address (which device you want to talk to).  This is sometimes called the Slave Address.  This is the first address after the START bit.  The next byte is normally the Memory Address WITHIN the device.  If it is an EEPROM, then the Device Address is 0xA0 for a write to the device, and the Memory Address is the memory location you wish to access.  The routine "SendChar" only sends the Start bit and two bytes.  They are missing the data.  So my way around this was to edit the PE code to elevate the Write() and GetAck() routines to be accessible outside the module, and I used it after the EI2C1_SendChar routine to send the data.

    for(j=0;j<E2_LEN;j++){
      MyAddr = (byte)j;
      Err = EI2C1_SendChar(MyAddr);     // Send the Write address to EEPROM
      if(Err) WriteFailed = TRUE;
      Write(*ReadPtr++);                          // Send the data
      Acknowledge = GetAck();
      if(Acknowledge == NOACK) AckFailed++;
      ClkDown();
      EI2C1_SendStop();                         // Send the stop bit
      COP1_Init();
    }

There was one more problem, and that is the code is missing one clock in the entire protocol.  I only found it when using an oscilloscope to watch the lines.  Mind you, I'm working as a contractor out of my home ever since my job went to China, so I only have an old analog (not a storage) scope.

At the end of the GetAck() routine, the clock is left high after sampling the ACK on the data line.  Then the SendStop() routine drives the data low and then the clock high (which it already was), and finally the data high, which is the Stop bit.  The problem is that there is no clock at the end of GetAck() to clock the reception of the ACK from the slave.  So even though the software read the ACK, the device does not release the ACk because it did not get a clock from the controller.  So in my case, the writes kept failing.  I added a routine called ClkDown() and the device driver started working.

void ClkDown(void) {
  Inhr2_SetDir((bool)OUTPUT);       /* CLOCK LOW PULSE */
  Inhr2_ClrVal();
  Delay();
}

I suspect that this clock may also be missing from the reads as well, but I didn't want to change the GetAck() routine because it is used in other places, and my code is now working.  Notice that the above routine uses byte writes in a for loop rather than one block write.  I just wanted to keep things simple to get it working.

So the only devices I used on this part so far have been the IIC, the Serial Port and the GPIO pins.  I was thinking about using the analog comparator, but since 2 of the 3 PE beans have had bugs, I'm a bit nervous.  So I'm hoping we can help each other with a list of known bugs in the code generators.

Regards,

Virgil

[JimDon]

So you are saying that Freescale should  tell all distributors to ship back all products on the shelf so that they  can be repackaged with a new version of CW?

Wouldn't it just be simpler if you download the latest version?
If you find bugs in that, perhaps you will find some interest....

[WillDesignForFo]

Obviously not, Jim D!

Recalling the software would be rediculous.  When I got the CW Special Edition about 2 months ago, I installed it and checked for updates.  It said everything was up to date.  If I am missing something, like a special place to update beans, please let me know.  It was not obvious from the install.

Also, I saw that I could install CW6.0 or 6.1 for a 30-day trial, but I did not want to use that because I would not be able to support my code development or feature enhancements long-term.  I also cannot justify purchasing the full license at this time.  I just decided to put my nose to the grindstone and figure out how to get it done myself (with a few long nights).

Regards,

Virgil

[JimDon]

You somehow missed the fact that you can install special edition 6.2 forever.
And is has fewer limitations the 5.x.

Go here and download Special Edition 6.2 and start a new buglist.

Sorry if you misunderstood.

[WillDesignForFo]

OK.  So I successfully installed CW 6.2 this time, next to my CW 5.1 directory.

When I tried the other day, I uninstalled 5.1 first, and the install wizard for 6.2

complained that I was over the 30-day trial for this tool, and it would not let me

install.  This time, I left 5.1 installed (using more disk space), and it still complained,

but it did the install anyways.

So here's what I found on 6.2:

1.  The baud rate value that I'm using is now correct under 6.2, so that has been fixed.

2.  The SW_IIC code has also changed.  They have added some timeouts waiting

     longer for ACK on slower devices.  They have also added in the missing clock.

     However, they still only send two bytes of data on a byte write, as opposed to

     the three bytes required.  A single-byte write should be:

     START---DeviceAddress---Ack---MemoryAddress---Ack---WriteData---Ack-STOP.

     However, the code only does:

     START---DeviceAddress---Ack---MemoryAddress---Ack

     So I still need to change the code around.  It's better, but still not completely working.

So please excuse me if I'm breaking protocol by asking a different question on this thread, but...

I found some IIC_EEPROM beans available for download on ProcessorExpert.com:

http://www.processorexpert.com/mcEEPROM.html#EEPROM_I2C_24xxx

Now I downloaded the UBAA-7.4 bean for HC(S)08 and installed it into CW via the ProcessorExpert Update Menu: "Update Processor Expert from Package...", and I added the file and quit and restarted CW.  I can see the installed bean when I select menu item: "View/Installed Beans Overview", but I cannot find the bean in the bean selector menu to actually use it.  Any advice?  The bean name in the Overview is called "EEPROM_I2C_24xxx", Author=Processor Expert / MP,SA; Current version 01.017; sw\EEPROM_I2C_24xxx.dmo; sw\EEPROM_I2C_24xxx.drv.

Any idea how to actually use this bean?  Do I need a special license for this?

Thanks in advance,

Virgil

Message Edited by WillDesignForFood on 2008-07-21 04:57 AM

[JimDon]

Glad to here you got 6.2 to work for you. It is a much better version - it does have the file limit removed.
Below is some code I used to talk to an I2C EEPROM using the PE code as it should be. I created a block that has the address and data in it and sent it as a block. As for those beans you down loaded, no comment. You may have to adjust the code for your EEPROM.

Code:

// This struture holds the address to read or write
// and the data.
typedef struct _i2cmessage {   byte addresshi;   byte addresslo;   byte buffer[128];} I2CMESSAGE;// Global message buffer.
I2CMESSAGE _i2cmsg;#define I2CADDR  0xa0 >> 1word WriteSector(word sector) {   word size;   // sectors are 128 bytes on this device, and it auto erases.
   word address = sector * 128;   // Address the device with the write command.
   EI2C1_SelectSlave(I2CADDR);  
   _i2cmsg.addresshi =(byte)(address>>8);   _i2cmsg.addresslo =(byte)(address & 0xff);   // Note that SEndBlock sends the chip address firs.
   EI2C1_SendBlock(&_i2cmsg,(word) sizeof(I2CMESSAGE),&size);  
   return size;    }// Test code to write address in address
// sector is a global set else where.
byte cmd_i2c_aia(char * s)
{
 word rc;
 byte i;

 s = s;
 for( i = 0 ; i < 128 ; ++i )
   _i2cmsg.buffer[i] = i;
  
 rc = WriteSector(sector); 
 
  return 0;
}
word ReadSector(word sector) {   word size;   // Sectors are 128 byte.
   word address = sector * 128;   EI2C1_SelectSlave(I2CADDR);   _i2cmsg.addresshi =(byte)(address>>8);   _i2cmsg.addresslo =(byte)(address & 0xff);
   // For reading, send the addres to read from first.
  EI2C1_SendBlock(&_i2cmsg,(word) 2 ,&size);
  // This will send the slave address with bit 0 hi for read.
  // just use the data part to read into.
  EI2C1_RecvBlock(&_i2cmsg.buffer[0],(word) 128 ,&size);  return size;    }

 

[WillDesignForFo]

Jim:

Agreed.  That should work.  The funky part is that you had to create a data structure that included the address at the head of the data for a block operation.  To me, it would have been much more straightforward to add another parameter for the write address.  Something like:

EI2C1_SendBlock(&_i2cmsg, Address, (word) sizeof(I2CMESSAGE),&size);

That's all.  It just makes it more intuitive to use.

BTW, I did get it to work in 5.1 anyways.

Regards,

Virgil

[JimDon]

The address is there only because it is an EEPROM and its format is dependant on the device.
I would not expect generalized I2C rountine to know about the details of the chip I am talking to.

Just wondering, why to  you want to use 5.1?

[WillDesignForFo]

Regarding the IIC routine, this is not just specific to EEPROM.  That just happens to be what I'm using.  The protocol to read/write to an IIC device requires a Device Address and a Word Address, plus the data (either received or sent).  Look at page 12 of this Real Time Clock chip:

http://datasheets.maxim-ic.com/en/ds/DS1340-DS1340C.pdf

How can you expect to read the bytes for the hours, minutes, and seconds without addressing them within the device?

Now why have I been using 5.1?

Because it was my understanding that 6.x was only good for 30 days, whereas 5.1 is valid forever.  After all, that's what the install told me.  So I just did my design in 5.1 so I had a platform that I could support long-term.  Since then I have learned that the 6.x is still valid after the 30 days.  So much for me trying to follow the rules!

Virgil

[JimDon]

Yes, but note for the RTC the "word" address is a single byte, vs two bytes for the EEPROM.
That's my point - after the salve address what follows is chip dependent.

If the EEPROM is greater than 64K, then it needs 3 or 4 address bytes. So there is no generic I2C "address" parameter. It just happens the EEPROM I wrote that code for is a 64K byte device and has 128 byte sectors.

To read the time you would send a byte that is 0 (to start at register 0), then ask to read 7 bytes.

So now can we forget about stick bug lists for 5.1?






Message Edited by JimDon on 2008-07-21 11:33 AM

[WillDesignForFo]

I think I already gave up on it 2 days ago.

I'm only replying because others are.

Regards,

Virgil

[JimDon]

On licensing:
 
Ok, it has been changed. What peg said is now true.

If you download SE, you will get Professional features for 30 days, then it will revert to SE.
Yet, there is still an eval version, however I really don't see what purpose  that, as it is basically the same deal.

It used to be an SE license had no time out, you just got SE features and that was it, and an eval was just good for 30 days, then you had to change it to an SE license.

I have officially asked that this be clearly explained on the web site, and that perhaps they would consider just dumping the eval version.

[ProcessorExpert]

Regarding to the EEPROM_I2C_24 bean.

It seems you have switched "on" the "Licensed" filter button in the Bean Selector window and you don't have the necessary licence. After switching this button "off" the downloaded free bean should be uncovered, however it will still not work.

It's necessary to have at least the "standart edition" licence for using free "software beans".

More information about licences can be found here:
http://www.freescale.com/files/soft_dev_tools/doc/fact_sheet/CWS-H12-FS.pdf

best regards
Vojtech Filip
Processor Expert Support Team
UNIS

[WillDesignForFo]

Jim:

Thanks for the reply.

So I downloaded "Special Edition: CodeWarrior for Microcontrollers" [V6.2] at the link you posted, but when I tried to install it, it said I was past the 30-day trial for the software.  So this is apparently the software I downloaded almost 2 months ago (when I was first having trouble with the software).  I decided then I wasn't going to work on a platform I could not support, so I removed it from my machine.

So tell me if I'm still missing something.

Regards,

Virgil

[peg]

Hello Virgil,

There is a recent post about this somewhere.
A Freescaler responded.
IIRC this is how it works. You get like a full licence for 30 days and then it reverts to special which lasts forever. You have to be careful with this sucker method, that you don't use stuff that won't work under special if your not going to fork out for it.

[JimDon]

Well, it has to do with the license.dat file in the C:\Program Files\Freescale\CodeWarrior for Microcontrollers V6.2 directory.
I can't say for sure what went wrong - are you sure you download Special Edition and NOT Evaluation?
Was the name of the file you downloaded CW_MCU_V6_2_SE.EXE?

As for peg's explanation of how the licensing works, that has not been my experience at all.
An eval license and a special edition license are two different licenses with two different license.dat files. When the eval expires you need to replace it. Perhaps this has changed, but that was how it used to work.

Which version did you download ? Yes, you still have misunderstood something. The special edition is good for 32K/64K 8/32 bit and unlimited files forever. You can not use lint and only 1K of c++. It is possible that you used some beans that are not included in SE, but I have can't say for sure which are included and which are not.

If you did not download and install SE file, then download that one. You could try downloading again, as I know the file has been changed since then. (you seemed to say that you downloaded 2 months ago).

Also, try it out creating a new project. If things go wrong, we will see that it gets fixed.

[JimDon]

Ok, I down loaded an installed the SE file I mentioned.
Does you license.dat file start like this? If you download the SE file, this is what you should get with the SE download. And think that what peg said is true, the for the first 30 days it will be a pro license. However, there is still an eval license download. Be sure you delete the directory that you uninstalled from, as perhaps you had an eval licence there and the installer did not over write it with the SE licence file.

#######################################################
# ( 843): HC08 V6.0 Special Edition
#######################################################








Message Edited by JimDon on 2008-07-20 12:15 PM