5 Replies Latest reply on Mar 28, 2020 8:22 AM by CaKu_4284131

    Mbed: Different (bad) behavior in Modustoolbox 2.0

    CaKu_4284131

      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?

        • 1. Re: Mbed: Different (bad) behavior in Modustoolbox 2.0
          DheerajK_81

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

           

          Regards,

          Dheeraj

          • 2. Re: Mbed: Different (bad) behavior in Modustoolbox 2.0
            DheerajK_81

            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

            1 of 1 people found this helpful
            • 3. Re: Mbed: Different (bad) behavior in Modustoolbox 2.0
              DheerajK_81

              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

              • 4. Re: Mbed: Different (bad) behavior in Modustoolbox 2.0
                DheerajK_81

                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

                1 of 1 people found this helpful
                • 5. Re: Mbed: Different (bad) behavior in Modustoolbox 2.0
                  CaKu_4284131

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

                   

                  Thanks,

                   

                        Carl