Hi Quentin
Thank you for sending your code. In fact I could also reproduce the problem on the M52259EVB with any USB class when using CW7.2.
First of all, it is necessary to have the SD card support enabled to be able to work with MSD. This is because MSD and the SD card operate together and so it will result in a build error when only MSD is built without SD card enabled.
static const UTDISK *ptrDiskInfo = 0;
This is also correct. The pointer has been modifed to a const pointer recently since the caller should never attempt to change any contents. This means that the compiler will also generate errors if the user were to attempt this. It is a detail but probably the cleanest implementation. This adjustment was indeed missing in the last Coldfire version and so caused either a warning or an error - CW7.2 is very strict (at least with the project settings used) and so choses an error - other compilers may generate a warning and others just ignore it. In any case it has been corrected like this.
What I found is that CW7.2 is making an error in the USB interrupt routine - when I tried with CW7.1 (and some other compilers) it was OK. So I looked into this and identified the following problem and a workaround for it.
The code is as follows:
while ((ucUSB_Int_status = (unsigned char)(INT_STAT & INT_ENB)) != 0) { // read present status
if (ucUSB_Int_status & ~TOK_DNE) {
The main loop stays in the interrupt routine as long as there are enabled interrupt sources pending. When this is the case there is a check to see whether it is a TOK_DNE or any other type (bus state changes). It is expected that the check is therefore if (ucUSB_Int_status & 0xf7) since TOK_DNE is 0x08.
The first interrupt that arrives is a USB_RST (0x01) and so it is expected that the first check causes the reset handler to be executed (not a token interrupt) but this is never true. I looked at the code generated and see the following
moveq #0,d4
move.b d1,d4
move.l d4, d3 in case of the reset bit pending the value in d3 ix 0x01
bclr #3, d3 this instruction does a test of the bit 3 (that is the TOK_DNE bit) and the sets this bit to zero
beq.w .... this branch is conditional on the zero bit which was set depedning on the state of bit 3 in the last instruction
If I have understood this correctly the code that the compiler has generated is wrong since it is actually setting the brach condition based on the TOK_DNE bit which is not what the c code wants (it wants it based on all other bits apart from this one...)
A work around that avoids this compiler error is to use a second variable:
register unsigned char ucIntTest;
while ((ucUSB_Int_status = (unsigned char)(INT_STAT & INT_ENB)) != 0) { // read present status
ucIntTest = (ucUSB_Int_status & ~(TOK_DNE));
if (ucIntTest != 0) {
The use of an intermediate variable separets the mask and the branch check and then CW7.2 gets it right.
Out of interest I checked what CW7.1 did with the original code and it looks like this:
moveq #0,d5
move.b d1,d5
move.l d5,d3
bclr #3,d3
tst.l d3
bne.w ....
Notice that it has an additional test and doesn't directly use the result of the bclr, which is then correct.
Then I tested another very simple workaround that also did it for CW7.2
while ((ucUSB_Int_status = (unsigned char)(INT_STAT & INT_ENB)) != 0) { // read present status
if (ucUSB_Int_status & (USB_RST | USB_ERROR | SOF_TOK | SLEEP | RESUME | ATTACH | STALL)) {
moveq #0,d4
move.b d1,d4
move.l d4,d3
bclr #3,d3
tst.b d3
beq.w ...
This is however rather surprising since it looks as though tthe compiler to still use the bclr (it understands that all other bits are set) but it then correctly checks the result for the branch... the use of ~ had presumably caused some confusion: Very strange but hopefully the problem is solved like this!
Regards
Mark
P.S. In your project you had the GLCD active, which can presumably be removed so that the GLCD task is not trying to initialise a display that is probably not attached.
