PSoC™ 6 Forum Discussions

Hi Everyone,

I am writing a program that opens a .cycad2 file and sends the data over UART. In the program I format the flash rows using the Infineon-AN213924_PSoC_6_MCU_Device_Firmware_Update_Software_Development_Kit_Guide-ApplicationNotes-v09_00-EN user guide and from a record of a successful DFU programming over UART which shows the DFU protocol and formatting.

I have successfully programed a device using the boot loader app from PSOC creator. I am using the AN213924 example project with App0, and App1 as a working model to test my code. 

My question is how is the CRC-32C calculated on page 54 of the guide for the 0x49 DFU command (Program Data)? I have a function to calculate CRC-32C, but I'm unsure how the row of data in the .cycad2 is broken down to generate the CRC-32C bytes? Are all the bytes in the row added together, then a CRC-32C is performed on the result? Is the flash row broken into 4 byte 32 bit number, then added together for the CRC-32C? I don't see how it is specified in the document. All the other data packets with the DFU 0x37 command use a checksum which I have been able encode and matches the UART data I have observed.

I see these 4 bytes while watching the a successful DFU programming with App1 on the UART bus with the 0x49 command: 0x15, 0x61, 0x56, and 0x48 which I think is 0x48566115 to match the byte order of the other byte fields. 

The row that generated this CRC-32C is below from the app1 .cyacd2 file: 

:0000041000200008230104100D00000085010410000000000000000000000000000000000000000000000000000000008101041000000000000000008101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041081010410810104108101041010B5064C2378002B07D1054B002B02D0044800E000BF0123237010BD3C07000800000000B8240410084B10B5002B03D00749084800E000BF07480368002B00D110BD064B002BFBD09847F9E70000000040070008B8240410E8010008000000007047FFF7FDFF72B60F4C104DAC4209DA21686268A368043B02DBC858D050FAE70C34F3E70A490B4A0020521A02DD043A8850FCDC084809490860BFF34F8F00F005F900F01DF8FEE7BC240410D42404103C070008140900080001000808ED00E0FEE7FEE700B504207146084202D0EFF3098001E0EFF30880043001F04BFBFEE710B562B6014800F067F9FEE70000051010B5002001F0BAF810BDC04670B56249E0239B00CB580F2213401A00D0329200525807210A40032A05D0042A06D0002A12D15A4814E05A4A106811E01A00C0329200554952581F210A40112A06D0132A

How is this CRC-32C evaluated? This is the last part I need to figure out to get my remote DFU updated program working.

I am trying to get the MCUBoot to work with my custom board (using a dual data pin SPI chip).

The original example worked fine with the devkit (CY8CPROTO-062-4343W).

In the custom board, I am using MX25V1635FM1I as serial flash (with only two pins used for data).

I changed the serial flash driver using QSPI Configurator (which is being used correctly by blinky_cm4 correctly.

But it appears that the bootload_cm0p is using auto detect SFDP (which attempts to use the serial flash as octal device) which does not work (since the Cy_SMIF_MemSfdpDetect uses CY_SMIF_WIDTH_OCTAL and populates the wrong read commands during the initialization. 

What is the proper way to initialize the SMIF or flash_qspi driver from bootloader to use the correct SPI settings?

I was able to get it working by changing CY_SMIF_WIDTH_OCTAL to CY_SMIF_WIDTH_DUAL in Cy_SMIF_MemSfdpDetect, but I doubt that is the correct way to handle this situation.

I cannot get the EEPROM working right in my program.  I ran the EEPROM demo project and it works but I cannot use the same code because the compiler rejects it:

That is really tiny, hope it is readable.  Anyway the compiler says that it cannot assign to the userFlashStartAddr.  Maybe this has something to do with it being const, but in the example this works.  After some trial I discovered that the example was using EEPROM version 2.0 and I was using 2.2 - Aha! I said, but changing to 2.0 makes no difference.

if I instead use EEPROM_Init ((uint32_t)EEPROM_em_EepromStorage). the init returns success, but every attempt to write to the EEPROM fails with the failure return value.  

So  It seems that I have to use the middleware Cy_ functions, but the complier will not accept the start address...

(Oh, and I am enabling global interrupts before the init function is called.)

Any help???

Thanks, Russ

I am porting the MTB WiFi_Scan app from a DevKit to my hardware.  The DevKit uses PSoC6 6247BZI-D54 P2 for the SDIO port.  I need to use P12.  I updated the pins in Device Configurator, updated cyreservedresoures.list, and immediately ran into problems running the code because of mbedtls (fixed)  and then I thought the  code should work but lo and behold there is no SDIO_CLK and the code gets stuck trying to send an SDIO command....   it seems the SDIO port using UDB0 on P12 just does not work for some reason I have not been able to debug...   Has anyone gotten P12 to work as SDIO ?

Any help greatly appreciated !!!!

Thanks

Mark

we have working with one IOT based project on PSOC6 WIFI BT PROTOTYPING KIT.I was attempting to post some data from code to PHP server .I have used webserver code and http_client code for reference. I am unable to get the value that i am sending from code to server. I am attaching the file. Could you please help me to sort out the issue .The terminal output also I am attaching with this

Hello,

I am supposed to interface a SGP40 VOC Sensor Waveshare 20168 SGP40 VOC Sensor, 17,90 € - Welectron with a CY8PROTO-062-4343W board via I2C. Since I have no experience with this, I copied the code snippets from here PSoC 6 Peripheral Driver Library: I2C (SCB) (infineon.github.io) into Eclipse IDE (attached). The output when running the code is only 0s. I don’t know how to modify the code to make it work or if this is even possible without writing a whole new library for the sensor?

Thanks for any advice!

Hi there, we are looking to order more CY8CPROTO-062-4343W to run on our prototype controller boards. We need about 10 boards. Availability seems to be 0 around the world as of today, apart from 2 on AVnet. 

Is the proto board still in production or is it obsolete? Will it be available again in the next 4-6 weeks? If not we'll have to switch to a different architecture to meet investor milestones on getting the product out to testing. We'd obviously like to avoid that.

Thanks for any insight into the magic of electronics supply chains! 

Hi

I was tried to program CY8CPROTO-062-4343W with kitprog3 debugger .It showing some error .Could you please help me to sort out the error. I am attaching the errors showing in eclipse ide.