Mbed: Different (bad) behavior in Modustoolbox 2.0

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
CaKu_4284131
Level 5
Level 5
50 replies posted 25 replies posted 10 likes received

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!

pastedImage_7.png

Zoomed in on the CMD8:

pastedImage_9.png

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

pastedImage_5.png

Zoomed in on the CMD8:

pastedImage_6.png

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?

0 Likes
1 Solution

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

View solution in original post

5 Replies
DheerajK_81
Moderator
Moderator
Moderator
First comment on KBA First comment on blog 5 questions asked

Yeah strange. I was able to reproduce your error. Currently debugging to find out the root cause.

Regards,

Dheeraj

DheerajK_81
Moderator
Moderator
Moderator
First comment on KBA First comment on blog 5 questions asked

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

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

0 Likes

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

Yes, it works for me if I use the Release profile when I do the export.

Thanks,

      Carl

0 Likes