- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm having a problem that I can recreate using the FATFileSystem example at .FATFileSystem - APIs | Mbed OS 5 Documentation. I'm instantiating an SDBlockDevice to talk to an SD card connected to a PSoC® 6 BLE Pioneer Kit (CY8CKIT-062-BLE) through SPI.
// Instantiate the SDBlockDevice by specifying the SPI pins connected to the SDCard
// socket. The PINS are:
// MOSI (Master Out Slave In)
// MISO (Master In Slave Out)
// SCLK (Serial Clock)
// CS (Chip Select)
SDBlockDevice sd(P12_0, P12_1, P12_2, P12_3);
// Call the SDBlockDevice instance initialisation method
if ( 0 != sd.init()) {
printf("Init failed \n");
return -1;
}
If I build this from the command line (Mbed-CLI), it works fine.
mbed compile --target CY8CKIT_062_BLE --toolchain GCC_ARM -f
CMD:0 . arg:0x0 . Response:0x1
CMD:8 . arg:0x1aa . Response:0x1
V2-Version Card
R3/R7: 0x1aa
CMD:58 . arg:0x0 . Response:0x1
R3/R7: 0x40ff8000
CMD:41 . arg:0x40000000 . Response:0x1
CMD:41 . arg:0x40000000 . Response:0x1
CMD:41 . arg:0x40000000 . Response:0x0
CMD:58 . arg:0x0 . Response:0x0
R3/R7: 0xc0ff8000
Card Initialized: High Capacity Card
CMD:59 . arg:0x0 . Response:0x0
init card = 1
CMD:9 . arg:0x0 . Response:0x0
SDHC/SDXC Card: hc_c_size: 15159
Sectors: 0xece000x : 15523840
Capacity: 7580 MB
CMD:16 . arg:0x200 . Response:0x0
sd size: 7948206080
sd read size: 512
sd program size: 512
sd erase size: 512
--- Mbed OS filesystem example ---
Mounting the filesystem... CMD:17 . arg:0x0 . Response:0x0
CMD:17 . arg:0x2000 . Response:0x0
CMD:17 . arg:0x2001 . Response:0x0
OK
Opening "/fs/numbers.txt"... CMD:17 . arg:0xa000 . Response:0x0
OK
Incrementing numbers (0/10)... CMD:17 . arg:0xa028 . Response:0x0
Incrementing numbers (1/10)...
Incrementing numbers (2/10)...
Incrementing numbers (3/10)...
Incrementing numbers (4/10)...
Incrementing numbers (5/10)...
Incrementing numbers (6/10)...
Incrementing numbers (7/10)...
Incrementing numbers (8/10)...
Incrementing numbers (9/10)...
Incrementing numbers (10/10)... OK
Closing "/fs/numbers.txt"... CMD:24 . arg:0xa028 . Response:0x0
CMD:17 . arg:0xa000 . Response:0x0
CMD:24 . arg:0xa000 . Response:0x0
OK
Opening the root directory... OK
root directory:
System Volume Information
numbers.txt
Closing the root directory... OK
Opening "/fs/numbers.txt"... OK
numbers:
CMD:17 . arg:0xa028 . Response:0x0
20
21
22
23
24
25
26
27
28
29
ÿ
Closing "/fs/numbers.txt"... OK
Unmounting... OK
Mbed OS filesystem example done!
Zoomed in on the CMD8:
However, If I run it in MTB2.0, I get different results. Using the CY8CKIT_062_BLE_mbed-os-example-blinky_debug launcher:
CMD:0 . arg:0x0 . Response:0x1
CMD:8 . arg:0x1aa . Response:0x1
V2-Version Card
R3/R7: 0x584849ab
CMD8 Pattern mismatch 0x1aa : 0x584849ab
Fail to initialize card
Init failed
Zoomed in on the CMD8:
The logic analyzer seems to show identical bus traffic on the SPI in both cases, as far as they (mutually) go.
Something strange seems to be going on in mbed-os/components/storage/blockdevice/COMPONENT_SD/SDBlockDevice.cpp, maybe around here:
// Get rest of the response part for other commands
switch (cmd) {
case CMD8_SEND_IF_COND: // Response R7
debug_if(_dbg, "V2-Version Card\n");
_card_type = SDCARD_V2; // fallthrough
// Note: No break here, need to read rest of the response
case CMD58_READ_OCR: // Response R3
response = (_spi.write(SPI_FILL_CHAR) << 24);
response |= (_spi.write(SPI_FILL_CHAR) << 16);
response |= (_spi.write(SPI_FILL_CHAR) << 8);
response |= _spi.write(SPI_FILL_CHAR);
debug_if(_dbg, "R3/R7: 0x%" PRIx32 "\n", response);
break;
What should I be looking for?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the previous response, I mentioned it is not a Debug or Release profile issue. The setup might have been injecting some noise, fixed that now. Tested the projects in mbed-cli and ModusToolbox for both Debug and Release profiles.
In mbed-cli, using the Release profile, it works correctly
mbed compile -t GCC_ARM -m CY8CKIT_062_BLE -f --profile release
However, using Debug profile, it fails:
mbed compile -t GCC_ARM -m CY8CKIT_062_BLE -f --profile debug
Similarly, this behavior is true for ModusToolbox as well. When you export to ModusToolbox, make sure you use the Release profile and you will observe the test passes:
mbed export -i eclipse_gcc_arm -m CY8CKIT_062_BLE --profile release
Then import into Modus, clean and build your project. Can you please check on your end and confirm if it now works for you?
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah strange. I was able to reproduce your error. Currently debugging to find out the root cause.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have forwarded your query to our product development team, who are looking into this. Thank you for your interest in Cypress products.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some updates:
The immediate cause of the SPI init failing is that the "CMD8 check pattern" does not match. We do not yet know why this is. We do now know several ideas of what it is not:
- It is not a debug vs. release issue. Both environments appear to be defaulting to release but exhibit no change in behavior if I switch to debug.
- It is not a difference in the toolchain. I am using a system install of GCC 6.3 with mbed-cli. I temporarily renamed the ModusToolbox tools-packaged GCC and rebuild to confirm
- It is not an issue with how the elf file is being downloaded. Programming the elf built-in Eclipse with CyProgrammer leads to the same failure. Using Eclipse to program the elf file produced by mbed-cli produces the same success.
The elf files differ, but that isn't necessarily significant in and of itself because it could be caused by things like differences in the order in which object files are passed to the linker.
The debugging is still on-going, will keep you updated on the developments. Thank you for your patience.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the previous response, I mentioned it is not a Debug or Release profile issue. The setup might have been injecting some noise, fixed that now. Tested the projects in mbed-cli and ModusToolbox for both Debug and Release profiles.
In mbed-cli, using the Release profile, it works correctly
mbed compile -t GCC_ARM -m CY8CKIT_062_BLE -f --profile release
However, using Debug profile, it fails:
mbed compile -t GCC_ARM -m CY8CKIT_062_BLE -f --profile debug
Similarly, this behavior is true for ModusToolbox as well. When you export to ModusToolbox, make sure you use the Release profile and you will observe the test passes:
mbed export -i eclipse_gcc_arm -m CY8CKIT_062_BLE --profile release
Then import into Modus, clean and build your project. Can you please check on your end and confirm if it now works for you?
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it works for me if I use the Release profile when I do the export.
Thanks,
Carl