Hi All
This is patch list collected since the release of V1.4. Check this when starting with the V1.4 package in case of any know issues.
1) CW 7.1.2. This is not an issue with the V1.4 package but a problem identified with the V1.4.2 CW patch. See
http://www.utasker.com/forum/index.php?topic=659.0 (CW7.1.1 is the recommended version or else the workaround solves the known error, but it has also been reproted that similar errors have cropped up in project application code, so best avoid)
2) Start up file for Bare-minimum SPI FLASH configuration:
http://www.utasker.com/forum/index.php?topic=654.msg2830#msg2830 3) GNU boot-loader project required a correction as detailed in the following thread:
http://www.utasker.com/forum/index.php?topic=675.msg2956#msg29564) The detailed chip type settings for use of the random number generator in Kirin3 chips is not correct for M52252, M52254, M52256 and M52258. See the following for the correction, as well a general configuration improvement needed to solve the problem:
http://www.utasker.com/forum/index.php?topic=693.05) Random number generator error can be corrected as pointed out by Dave here:
http://www.utasker.com/forum/index.php?topic=702.msg3049#msg30496) LAN_REPORT_ACTIVITY bug.
In
fnEthernetEvent() in
M5223x.c remove the lines labeled {113}. This was causing the interrupts to remain blocked - they were automatically opened again as soon as the frame had been handled, but this is not optimal.
#ifdef LAN_REPORT_ACTIVITY
//iInterruptLevel = 1; // {113} ensure interrupts remain blocked when putting message to queue
fnWrite(INTERNAL_ROUTE, (unsigned char*)EMAC_int_message, HEADER_LENGTH);// inform the task of event
//iInterruptLevel = 0; // {113}
#endif7) I2C bug.
If a new telegram is send by the application in exactly the time between the previous telegram's command to send the STOP condition and the bus becoming free (quite a short period of maybe a hundred CPU clocks or so) the second telegram's interrupt blocks. The following protects against it by waiting if the state is recognised:
In
fnTxIIC() in
M5223x.c.
if (ptIICQue->ucState & TX_ACTIVE) { // restart since we are hanging a second telegram on to previous one
*register_ptr = (IIC_IEN | IIC_IIEN | IIC_MSTA | IIC_MTX | IIC_RSTA);
}
else {
register_ptr += sizeof(unsigned long); // {116} move to status register
while (*register_ptr & 0x20) {} // {116} wait until the stop has actually been sent to avoid a further transmission being started in the mean time
register_ptr -= sizeof(unsigned long); // {116} move back to CR
*register_ptr = (IIC_IEN | IIC_IIEN | IIC_MTX); // set transmit mode with interrupt enabled
*register_ptr = (IIC_IEN | IIC_IIEN | IIC_MSTA | IIC_MTX); // set master mode to cause start condition to be sent
}
The three lines labeled with {116} are new. The wait will very rarely be required and is only very short when it does occur. There is no interrupt available to 'automate' this but this solution seems to be fine.Regards
Mark