Hi All
As with any new SW, some issues will be found only once it has been released...
So please report anything here and I will also use it to report any (hopefully) relative simply modifications which can be made to correct them. [All corrections will be integrated in subsequent SP or file updates].
So to get the ball rolling...
1. 28.8.2007: RTC demo when compiling with GCCThe interrupt needs to be defined differently for GCC use and so it crashes when the first minute interrupt arrives.
Correction is to add the following lines to m5223x.c somewhere in the middle of the #ifdef _GNU // GNU interrupt list (approx. line 71)
#ifdef SUPPORT_RTC
static void _rtc_handler(void) __attribute__((interrupt_handler));
#endif2. 30.8.2007: TCP counter reset when using new HTTP windowingI have had chance to start intensive tests with the new HTTP windowing method (mainly simulating error cases and checking that the handling is correct)
It is not looking bad but there will be some corrections and optimisations needed before using it in a production project.
There is one nasty little bug which is worth fixing because it can cause the HTTP socket to remain in a blocked condition if a connection is reset by the client as a consequence of other possible less-serious problems.
In TCP.c add the following in the TCP_STATE_LISTEN state
#ifdef HTTP_WINDOWING_BUFFERS
ptr_TCP->usOpenCnt = 0;
#endifjust after the line ptr_TCP->ucTCPInternalFlags = 0; // start with flags cleared (at about line 1195)
3. 30.8.2007 Boot loader binary conversion utilityAs pointed out by 'Kremer', the CodeWarrior version 6.4 seesm to produce binary files in Motorola binary format rather than raw binary format. See
http://www.utasker.com/forum/index.php?topic=36.msg155#msg155For this reason the new version of uTaskerConvert.exe recognised Motorola Binary files and converts them to an intermediate RAW binary format so that this should be of no concern to the user.
Kremer pointed out an error which I made which could (or better - would) cause a block to be filled with 0xff and result in failure. This has now been corrected and the new converter can be collected from :
http://www.uTasker.com/software/V1.3/uTaskerConvertV1.2.zipCalling with "uTaskerConvert.exe -v" will return the version number to verify the correct one.
4. 4.9.2007 FLASHBAR value with SPI FLASH bootloader supportWhen the SPI FLASH boot loader support is used, the start address of the application is 0x1000 rather than 0x800. This is defined in the linker script file M52235EVB_BOOT_APP_FLASH.lcf but has side effects when the program entry is higher than 0x800 due to the fact that the value is set to reserved bits in the FLASHBAR - this can have serious consequences and was found to be the cause of the FLASH -> RAM DMA difficulty noted in the SP5 release notes (as well as others).
hardware\M5223x\startup.s should be modified as follows
/* Initialize FLASHBAR */
/* move.l #__FLASH,d0 don't take from linker script because it is incorrect *//* move.l #0x121,d0 */ /* No workaround 1 {1} set value assuming FLASH is at low address */
move.l #0x161,d0 /* This is the workaround 1 due to the Internal FLASH Speculation error in the first devices */ movec d0,RAMBAR0
After this correction has been made, the conditional use of DMA_MEMCPY_SET in app_hw_m5223x.h can be removed.
5. 5.9.2007 IRQ8..IRQ15 mask correctionThanks to Neil D. for pointing out an error in the IRQ8..15 edge port configuration which was stopping the interrupts from being serviced. This was a surprise because I did believe that all had been check, but this can not have been the case!
If you need to use these IRQs (the IRQ1..IRQ7 are fine) please make the following code corrections.
- in m5223x.h add the following define:
#define IRQ_ICR_8_15_START (unsigned char *)(INT_CTRL_1_ADD + 0x60)Place it just before the definition of IC_ICR_1_32 at about line 787. This address is used to set up the interrupt level.
- in M5223x.c make the following code change in the routine fnConfigureInterrupt() and case PORT_INTERRUPT
Use this
irq_ctl = IRQ_ICR_8_15_START + ucIRQ_bit;
*irq_ctl = ((((INTERRUPT_SETUP *)ptrSettings)->int_priority & ~PRIORITY_MASK) | INTERRUPT_MID_POINT_PRIORITY); // define level with Mid-Point priority for this interrupt
IC_IMRL_1 &= ~(MASK_ALL_INT); // ensure global mask removed
IC_IMRH_1 &= ~(IRQ8_PIF_INT_H << ucIRQ_bit); // unmask interrupt source instead of this
#ifdef CHIP_80_PIN
irq_ctl += (EDGE_INTERRUPTS-1);
#else
irq_ctl += ucIRQ_bit + 8;
#endif
*irq_ctl = ((((INTERRUPT_SETUP *)ptrSettings)->int_priority & ~PRIORITY_MASK) | INTERRUPT_MID_POINT_PRIORITY); // define level with Mid-Point priority for this interrupt
IC_IMRH_1 &= ~((IRQ8_PIF_INT_H << (ucIRQ_bit - 1)) | MASK_ALL_INT); // unmask interrupt sourceThe interrupts were not arriving due to the fact that they were not being unmasked correctly and also the interrupt priority was being set in the wrong controller (0 rather than 1).
After making the change IRQ8..IRQ15 will operate correctly - hand on heart - I just tested it on the M52235EVB. Note that if you use the 80 pin (as is on the M52233DEMO) it only actually has IRQ11 available in the second Edge port block.
6. 7.9.2007 SPI_FILE_SYSTEM supportIf you would like to use the external EEPROM based file system in the SP5 there are a couple of small mods to make so that the compiler doesn't complain. Note too that SPI_SW_UPLOAD can not be used together with SPI_FILE_SYSTEM.
In M5223X.c:
1. Correct the line
#elif SPI_FILE_SYSTEM (
invalid syntax) to
#elif defined SPI_FILE_SYSTEM (about line number 2110)
2. Declare the function
int fnWriteBytesEEPROM() (
about line 2125) as a static function
static int fnWriteBytesEEPROM()7. 10.9.2007 I2C interruptThere was a small improvement made to the I2C interrupt routine which allows several reads and writes to be successfully queued in the driver. But it has been found that the modification was not made correctly and the code leaves the processor interrupts blocked after a complete message has been sent.
The correction is in M5223x.c,
static __interrupt__ void _IIC_Interrupt(void)Just before the return; in the middle of the interrupt service routine add
iInterruptLevel--; at about line 2560
8. 12.9.2007 SPI FLASH power up delayIt has been found that the SPI FLASH (AT45DBxxxx) requires a delay of at least 20ms from the time the system power reaches its minimum operating level until the device is ready for use. In circuits with an external watchdog - usually generating a reset pulse on power up of around 150ms - the Coldfire will not try to access the device until after this time and so all is OK.
However the M5223X often uses its internal reset circuitry, which means that the processor starts operating within around 1ms of the system supply voltage reaching ats lowest operating level. This causes difficulties on power up (but not on subsequent resets) when operating with the external SPI FLASH.
The solution is to add start up delays to the projects with SPI FLASH; the uTasker demo project and also the bootloader when supporting the chip. This then ensures that the device is always correctly detected on power up as well as normal reset.
The changes to make are:
- in M5223x.c, in the routine fnCheckAT45dbxxx() add (at the beginning of the routine after the line 'volatile unsigned char ucID[4];')
volatile unsigned long ulDelay = (BUS_CLOCK/12000) * 25; // 25ms start up delay
while (ulDelay--) {}; // Start up delay to ensure SPI FLASH ready
The factor BUS_CLOCK/12000 is an empiric value which ensures a delay in ms for any clock rate the project will be using.
- in M5223X_boot.c [when using the SPI FLASH capability of the boot loader], in the routine fnCheckAT45dbxxx() add (at the beginning of the routine after the line 'volatile unsigned char ucID[4];')
volatile unsigned long ulDelay = (OSCCLK/10000)) * 25; // 25ms start up delay
while (ulDelay--) {}; // Start up delay to ensure SPI FLASH ready
The factor OSCCLK/10000 is an empiric value to obtain a delay in ms since the boot loader runs at the oscillator rate (doesn't set PLL).
9. 12.9.2007 UART Status register declarationThis is in fact not an error introduced in the SP5 but something which has always been '
not-quite-correct...'.
Depending on the compiler and its optimisation settings, it is possible for registers to not be polled as expected if they are not declared as being of '
volatile' nature.
Therefore all registers which require this characteristic are declaration so... except for the UART status registers.
So please make the following changes in M5223x.h.
USR_UCSR_0 *(
volatile unsigned char *)(UART_ADD + 0xXX)
USR_UCSR_1 *(
volatile unsigned char *)(UART_ADD + 0xXX)
USR_UCSR_2 *(
volatile unsigned char *)(UART_ADD + 0xXX)
This will ensure that a new compiler version doesn't suddenly optimise an important loop aways.
Ooops. Sorry about that.
10. 10.10.2007 LCD in 4 bit modeWhen working with an LCD in 4 bit mode the following corrections are needed to ensure that LCD reading and bus timing is always correct.
In app_hw_m5223x.h add teh following new macro to the LCD macro block
#define DELAY_ENABLE_CLOCK_HIGH() O_CONTROL_PORT_DAT &= ~(O_CONTROL_EN);
In lcd.c add the delay between reading two nibbles (at aroudn line 198):
DELAY_ENABLE_CLOCK_HIGH(); // ensure the second write is not too fast when in 4 but mode // since we are in 4 bit mode we must repeat clocking to ensure read completed
CLOCK_EN_HIGH();
In the same routine (
fnReadDisplay()), reverse the nibble shift directions in the two places that it occurs:
#if DATA_SHIFT_LEFT > 0
RdData_msb
>>= DATA_SHIFT_LEFT; // shift into position
#elif DATA_SHIFT_RIGHT > 0
RdData_msb
<<= DATA_SHIFT_RIGHT; // shift into position
#endif
and finally... (in the same routine) the nibble shift direction:
return ((unsigned char)(RdData_msb | (RdData_lsb
>> 4))); // return the data byte read
11. 13.11.2007 Failing mono-stable task timer (usually Watchdog task)I must apologise to A.T. who found this bug. It is new in the SP5 and appears when there is a task in the task table defined to use NO non-stable timers (neither has a delay, nor a repetition, nor a reserved timer). In this case it is incorrectly counted and the result is that the start of the timer list gets shifted, effectively losing the first timer resource (belonging usually to the watchdog task).
In the simulator this immediately leads to the watchdog firing and the simulator terminating. On the target the watchdog LED doesn't blink and the watchdog will fire after 2s (if not disabled).
The fix is not difficult but does require a chunk of code to be replaced.
In uTasker.c search for the following line of code in uTaskerStart() and replace the content as follows:
if (nr_of_timers) {
...
} if (nr_of_timers) {
tTimerList = (TTIMETABLE*)uMalloc((MAX_MALLOC)(nr_of_timers * sizeof(TTIMETABLE) + sizeof(tTimerList->ptTaskEntry))); // get exact required timer list space
ptFillTable = tTaskTable; // establish initial timer list
while ( ptFillTable->pcTaskName ) { // start at top and work down to bottom
int iTimerEntryValid = 0; // {7}
if ( ptFillTable->TaskDelay != 0 ) { // delayed start required
if (NO_DELAY_RESERVE_MONO == ptFillTable->TaskDelay) { // place holder only so remove the delay
ptFillTable->TaskDelay = 0;
}
tTimerList->taskDelay = ptFillTable->TaskDelay;
//tTimerList->ptTaskEntry = ptFillTable; // {6}
//tTimerList++;
iTimerEntryValid = 1; // {7}
}
else if ( ptFillTable->TaskRepetition != 0 ) { // no start delay but repetition
tTimerList->taskDelay = ptFillTable->TaskRepetition;
//tTimerList->ptTaskEntry = ptFillTable; // {6}
//tTimerList++;
iTimerEntryValid = 1; // {7}
}
if (tTimerList->taskDelay != 0) {
tTimerList->ucTimerEnabled = 1; // mark that the timer is active {6}
}
if (iTimerEntryValid != 0) { // {7}
tTimerList->ptTaskEntry = ptFillTable; // enter the function
tTimerList++;
}
ptFillTable++;
}
//tTimerList->ptTaskEntry = 0; // end of table (uMalloc returns zeroed memory)
tTimerList -= nr_of_timers;
}
The comment {7} indicates the lines which are different.
Fortunately the bug is very obvious in the simulator. If you don't experience it it means that you have no tasks without timers. If you do experience it, replacing the code above will sort it out.
12. 30.11.2007 UARTs 1 and 2 in simulatorThe serial interface demo uses UART0 by default. This can be changed in app_hw_m5223x.h for either UART1 or 2 if desired. Eg. #define DEMO_UART 1
A correction in the simulator is however also necessary to be able to map these to the PC COM ports. Please make the following changes to the argv[] array index to correctly match the interface.
In M5232XSim.c,
extern unsigned long fnSimInts(char *argv[]) {
...
if (iInts & CHANNEL_0_SERIAL_INT) {
ptrCnt = (int *)argv[0]; <- OK
...
if (iInts & CHANNEL_1_SERIAL_INT) {
ptrCnt = (int *)argv[1]; <- set 1
....
if (iInts & CHANNEL_2_SERIAL_INT) {
ptrCnt = (int *)argv[2]; <- set 2
....
}
Note also that if support for DMA on the UARTs is enabled, only UART0 and UART2 support DMA transmission (UART1 can support DMA reception but is not used like this in the demo project). Don't configure UART1 to use DMA on transmission (eg. tInterfaceParameters.ucDMAConfig = 0;)
13. 21.01.2008 Stopped GlobalMonoTimer can cause other timer to fire too earlyPlease see the following for details about this one and the patch.
http://www.utasker.com/forum/index.php?topic=158.014. 26.01.2008 FLASH state-machine clock frequency (FCLK) correction Please see the following for details about this one and the patch.
http://www.utasker.com/forum/index.php?topic=165.0Regards
Mark
