cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ 4

RideMaker
New Contributor

I'm picking up a project and haven't used the Cypress PSOC parts before.  I have two board variants with two different PSOC 4 BLE parts in them: CYBLE-224116-01 and CYBLE-224110-00.  I have an iOS app I need to update to make FW upgrades to these units and it needs to be able to determine which part is being targeted.

My first round of research hasn't turned up how to retrieve a hardware version string from the unit.  I suspect that it is stored as a default characteristic on FW images generated by PSOC creator...but I'm still very new. What's an easy what to do this?

0 Likes
17 Replies
Renate
New Contributor II

Do you have a "Device Information" (service) in your BLE profile? You can (manually) add:

  • Manufacturer Name String
  • Model Number String
  • Serial Number String
  • Hardware Revision String
  • Firmware Revision String
  • Software Revision String
  • System ID
  • IEEE 11073-20601 Regulatory Certification Data List
  • PnP ID

Or did you mean getting silicon ID?

0 Likes
Renate
New Contributor II

If you have "Device Information" (service) in your BLE profile you can add (manually):

  • Manufacturer Name String
  • Model Number String
  • Serial Number String
  • Hardware Revision String
  • Firmware Revision String
  • Software Revision String
  • System ID
  • IEEE 11073-20601 Regulatory Certification Data List
  • PnP ID

Or did you mean silicon ID?

0 Likes
Renate
New Contributor II

In "Device Information" (service) in BLE Profile you can put (manually):

Manufacturer Name String
Model Number String
Serial Number String
Hardware Revision String
Firmware Revision String
Software Revision String
System ID
IEEE 11073-20601 Regulatory Certification Data List
PnP ID

0 Likes
Krupashankar
Moderator
Moderator

Hi @RideMaker ,

You will be able select the device for which FW upgrade to be performed in iOS app

Please refer to section 1.6.1.3 in document: https://www.cypress.com/file/198621/download

Please enter the device details and appearance in GATT profile to detect the exact device.

Please refer to the document for DFU over BLE  for further details: https://www.cypress.com/file/198301/download 

 

Thanks,

Krupashankar

0 Likes
RideMaker
New Contributor

I'm very new. It appears presently the GATT\GAP stuff pertains to the BLE radio config. I need the hardware version string for the PSOC part as a whole.  Can that be deduced from the BLE radio data?

0 Likes
Renate
New Contributor II

@RideMaker wrote:

Can that be deduced from the BLE radio data?


The "BLE radio data" is just what you put in there. You have two hardware models. They have incompatible software so you have two separate builds. In one of them you (manually) put in "Widget 1.05X (CYBLE-224116-01)" and in the other "Widget 1.07Y (CYBLE-224110-00)"

You're not saying that you want to do this all with one image? Are the silicon IDs the same? If they're not you probably can't program them the same.

0 Likes
PratikshaV
Moderator
Moderator

Hi,

If you are referring BLE radio data to Advertising packet then add a "Device information" service in profiles and you can make changes in GAP settings of BLE component according to  screenshot which is  attached below. Here you can manually add data and this data can be seen through advertising packet during advertising state. Please let me know if this helps.

Regards

Pratiksha V

0 Likes
Renate
New Contributor II

There's no particular need to put it in the Advertising data. Just having a GATT characteristic in the Device Information service will allow you to query it when you're connected.

0 Likes
RideMaker
New Contributor

If I'm reading this correctly, all the solutions would require code modification.  I'm looking for a solution that will work with the unmodified FW builds that are already deployed to the field.  How could this be done?

0 Likes
Renate
New Contributor II

I don't know why you would want to do this, but you could set the Device Information characteristic at runtime.

case CYBLE_EVT_STACK_ON:
   CyBle_DissSetCharacteristicValue(CYBLE_DIS_MODEL_NUMBER, 6, (uint8 *) "Widget");

Note that you can't change the length of the string characteristic. This is a limitation of the Cypress implementation.

0 Likes
Renate
New Contributor II

Oh, so you're saying that in the field you have two different hardwares with the exact same firmware and you want to do some sort of upgrade that will be different on the two hardwares?

You could flash everything with a dual-mode upgrade.

You could flash everything with an intermediate upgrade that would differentiate the two hardware then flash with the correct final upgrade.

Do these two hardwares have the same "silicon ID"? Is there some way to scan the peripherals that are different?

0 Likes
RideMaker
New Contributor

Yes!

As I understand it, if FW compiled for another device is uploaded, it can make the unit inoperable, so yes, I need to do a different upgrade depending on each hardware in order to pick the correct FW. 

So...I'm hoping for native functionality of some sort that will let me differentiate units because no explicit functionality was added in the FW builds to support it.

Scanning peripherals is a good idea, I'll check on that.

0 Likes
RideMaker
New Contributor

I've found where I can get the silicon ID, but the code I have hides what the data type is. Is it documented anywhere?

0 Likes
BiBi_1928986
Valued Contributor

Hello.

There is a code example to fetch the Unique Silicon ID.
Solved: PSoC UUID - Infineon Developer Community

The example gives a name to each parameter, but doesn't explain them in detail.

 

0 Likes
Renate
New Contributor II

"IDs" is a muddled topic. For instance,  it's not well documented that CyGetUniqueId() returns 64 bits in two 32 bit chunks. AFAIK, the "Unique Silicon ID" has nothing to do with the "Silicon ID". You can get the "Silicon ID" in SFLASH but you can also go to the horse's mouth and get it with an SROM call. Since I've already dealt with it that way to implement SWD programming, I wrote it that way.

#define SROM_KEY 0xd3b6
#define SROM_CMD_GET_SILICON_ID   0x00

void dump_id(void)
{
    uint32 id[2];

    CyGetUniqueId(id);
    DBG_PRINTF("Unique ID = %08lx %08lx\n", id[0], id[1]);
    
    *(uint32_t *) CYREG_CPUSS_SYSARG=SROM_KEY+(SROM_CMD_GET_SILICON_ID<<8);
    *(uint32_t *) CYREG_CPUSS_SYSREQ=0x80000000+SROM_CMD_GET_SILICON_ID;
    
    id[0]=*(uint32 *) CYREG_CPUSS_SYSARG;
    id[1]=*(uint32 *) CYREG_CPUSS_SYSREQ;
    DBG_PRINTF("Raw return: %08lx %08lx\n", id[0], id[1]);
    DBG_PRINTF("Silicon: %02lx%02lx%02lx%02lx\n", (id[0]>>8)&0xff, id[0]&0xff, (id[0]>>16)&0xff, id[1]&0xff);
}
0 Likes
RideMaker
New Contributor

Thanks for the info. I'm still trying to sort out what ID means what as well.  

My overall goal is to differentiate PSOC versions to flash the correct FW version via an iPhone app.  However, as I inspect the code I've been given, it looks like a basic check is present already.  However, it appears this check only matches the ID targeted by the built FW and the device targeted by the phone.  For this board, there are multiple device IDs in the field, so I'd like to have a mapping table of some sort. 

I suspect the check is part of the standard code generation. The OTAResponse file contains the below comments that seems to explain the structure a bit, but there's no mapping between the ID and rev and a real-world part that I can find.  Do you just have to do this experimentally?

 

// e.g. 01000800A3115313003C01019FFE17
    //      01
    //        00
    //          0800
    //              A3115313003C0101
    //              A3115313  Silicon ID
    //                      00  Silicon Rev
    //                        3C0101  Unknown data payload, not used in CySmart
    //                              9FFE  Checksum
    //                                  17  End of packet

The above answers pertain to retrieving ID\UUID values from the PSOC FW.  My 

0 Likes
Renate
New Contributor II

Was your last reply truncated?

Did you ever say definitely whether the hardwares you are trying to differentiate actually have different "Silicon IDs", the 32 bit ID found in datasheets, like 0x0e51199e for the CYBLE-012011-00?

I've never seen a sorted list of those, is there one?

0 Likes