QSPI shared mode question??

[v8dave]

Hi all,

I have SD card in my design using the same IO lines as the SD card in the DEV-100 board. I also have an SPI connection to a touchscreen controller.

I use a Semaphore to handle the file calls and the touch screen so that both are not going to use the SPI bus at the same time.

Everything is working great in debug mode but when I created a release version last night, it all stopped working as before. I can't get the touch screen to respond with position. It always returns the max position indicating a read error from the controller.

The SD card is now also behaving badly in that I am getting write errors to the flash disk. When you view the disk in Windows is shows as strange filenames, like the writing as being corrupted. For example, the MODBUS.CFG file looks like this.

M
OD
BUS.CFG

It appears as 3 files in the directory list but you can't open them in Windows. I have to re-format the flash to fix it.

Run it back under debug and it is fine!!

I have been looking through the code and I spotted a QSPISHARED.CPP file and wondered if anyone has experience of using this and do you think it would get rid of my issues? I am about to try and work my way through this and try it out!

Thanks
Dave...

[rnixon]

The major differences between debug and release builds is that compiler optimization is turned off. The effects will be execution speed (never use software timing loops), and also code can be optimized out. So you want to use the volatile keyword for any variables/references to external hardware.

[lgitlitz]

I would stick with the normal driver if you got that working already. The shared QSPI will function differently. To me this sounds like you are not fully protecting the sections using the peripheral.

You may want to change from semaphores to OSCrit objects since these can only exit from the same task that called the enter. I found the easiest way to do this is to bit bang the chip select for all your SPI devices and make a CS_hi and CS_lo function. This is how we control the CS lines in the mmc_mcf.cpp SD driver. Now the first line of all of your CS_lo function should have a OSCritEnter( &ShareQSPI, 0 );. Right after this you should configure the SPI settings for that device, then set the chip select. The CS_hi function should first set the CS hi and then the last line should be OSCritLeave( &ShareQSPI );. You should pull the mmc_mcf.cpp into your project and modify this files CS functions just like you need to for the other devices.

One oddity about the SD card is that the baud rate is dynamic. You should use the function spi_get_baudrate to save the baud before calling OSCritLeave. Also use the function spi_set_baudrate to set the baud after you configure the SD card settings in spi_cs_lo. The function spi_init has the SD card base settings you should configure in spi_cs_lo. The spi_init function should also have a OSCritEnter at the beginning since it calls CS_hi which will do an OSCritLeave.

[v8dave]

Thanks lgitlitz,

That seems to work just fine now. I think the inclusion of the QSPIInit call is what was causing the issue as without this the SPI setting for the touch screen controller would have been wrong. Now it reads and writes the files perfectly and the touch screen works too!!

This is a cool platform and now that I can run it in release mode with optimisation of 2 it is very quick. Now the windows popup lightning fast!! Nice!

Dave...

[v8dave]

I have have been a little premature with my reply.

I am still getting corruption somewhere in the code. See attached images of the directory on the disk before and after initalising and then trying to open the files for reading. All open calls fail and then when I remove the card and check in the PC, I see the corrupted names and strange directory entries.

I have confirmed that the OSCritEnter and leave are implemented correctly.

The touch screen drive never gets called unless the user touches the LCD anyway. It only gets called once on starup before any file system calls to setup the driver.

Dave...

[v8dave]

Mmm. Running in debug this all works fine.!

Here's the debug output from the application in debug build!!
----------------------------------------------------------
Waiting 2sec to start 'A' to abort
Configured IP = 0.0.0.0
Configured Mask = 0.0.0.0
MAC Address= 00:03:f4:04:54:b0
Attempting DHCP
DHCP IP Address: 192.168.1.108
Starting debugger
Initialized GDP tcp
Starting program
NV storage size = 338
FAT mount to SD/MMC successful
SD/MMC drive change successful
Files on disk:
------------------------------------------
Found File [AX9000BM.CFG] : 1800 Bytes
Found File [CANBUS.CFG] : 176 Bytes
Found File [DATALOG.TXT] : 12710 Bytes
Found File [MODBUS.CFG] : 480 Bytes
------------------------------------------
Sensor Config read OK
CAN config read OK
Modbus config read OK

OK. Now the same in release build!!
----------------------------------
Waiting 2sec to start 'A' to abort
Configured IP = 0.0.0.0
Configured Mask = 0.0.0.0
MAC Address= 00:03:f4:04:54:b0
Attempting DHCP
DHCP IP Address: 192.168.1.108
Starting program
NV storage size = 338
FAT mount to SD/MMC successful
SD/MMC drive change successful
Files on disk:
------------------------------------------
File [A] : 1800 Bytes
File [C<NBUS.CFG] : 176 Bytes
File [D<TALOG.TXT] : 12710 Bytes
File [M<DBUS.CFG] : 480 Bytes
------------------------------------------
No config, loading defaults
No CAN config, setting defaults
No Modbus config, setting defaults


No task are running at this point. Only after this initial configuration does it create and run the tasks. Each time I can create the flash disk on the PC formatted as FAT32 and copy the files to it. Each time I run it the same corruption happens. No files are opened, all I do is call f_mountfat and then display the files on the disk.

Here is the debug output with Optimisations set to NONE for release mode. Same problem. I suspect the main core code is optimised though!!

Waiting 2sec to start 'A' to abort
Configured IP = 0.0.0.0
Configured Mask = 0.0.0.0
MAC Address= 00:03:f4:04:54:b0
Attempting DHCP
DHCP IP Address: 192.168.1.108
Starting program
NV storage size = 338
FAT mount to SD/MMC successful
SD/MMC drive change successful
Files on disk:
------------------------------------------
File [D] : 12710 Bytes
File [M<DBUS.CFG] : 480 Bytes
File [A<9000BM.CFG] : 1800 Bytes
File [C<NBUS.CFG] : 176 Bytes
------------------------------------------
No config, loading defaults
No CAN config, setting defaults
No Modbus config, setting defaults

[v8dave]

Quick update.

I removed all the optimisation options from the make file for the NB system files and then rebuilt the system and my project.

Now it displays the disk contents and loads the files. Speed is still pretty good in release mode so I am going to leave it that way so that i can at least get the development done. Will need to see later why it fails though with optimisation enable (default looks to be level 2)

Debug follows:

Waiting 2sec to start 'A' to abort
Configured IP = 0.0.0.0
Configured Mask = 0.0.0.0
MAC Address= 00:03:f4:04:54:b0
Attempting DHCP
DHCP IP Address: 192.168.1.108
Starting program
NV storage size = 338
FAT mount to SD/MMC successful
SD/MMC drive change successful
Files on disk:
------------------------------------------
File [AX9000BM.CFG] : 1800 Bytes
File [CANBUS.CFG] : 176 Bytes
File [DATALOG.TXT] : 12864 Bytes
File [MODBUS.CFG] : 480 Bytes
------------------------------------------
Sensor Config read OK
CAN config read OK
Modbus config read OK
GPS not initialised or installed
Free RAM = 4689920
Logging started
Sensor Config saved
CAN fonfig saved OK
Modbus config saved OK

--------------------

The last 3 lines where after I made changes in the settings menu and then saved them.

Interesting to note that in my previous postings, the file lengths where correct.

Dave...

[lgitlitz]

It looks like you have zeroed in the problem to be something related to optimization. You should still get much better performance in release builds even with optimization disabled. When optimization level 2 breaks your code it is almost always a problem with volatile variables. At optimization level 2, any variables changes that the compiler does not "see" being modified or required will be optimized out if not declared volatile. There are a few common ways this can occur. One would be that your variable is controlled by hardware. For example, you have a device on the data bus. You make a pointer to the address of that bus. If this pointer is not declared volatile then the compiler will not think it is ever changing and will change the data at this address to be a constant. Another place I have seen variables optimized out is polling delay loops:
int x;
for( x = 0; x<10000; x++);
After optimization this loop will be replaced with x=10000; unless you declare x to be a volatile int.
I have also seen cases where pointers modified in interrupts are optimized out but this is rare. If possible I would make all of your global variables to be volatile to force them not to be optimized. Also any delay loops need volatile counts. Then if you get optimization to run correctly you can remove the volatiles one by one to see which one is the culprit.