Understanding config.hex

[ricardoquesada]

Hi,

TL;DR: How "config.hex" is used ?

a)  My understanding is the file "config.hex" (the one that gets autogenerated can can be found is codegentemp and it Generated_SourceCode/PSoC5/) contains the data to program the UDBs.

b) Also, my understanding is that the function cyfitter_cfg() programs the UDBs  when the devices reboots.

If so, I couldn't find out how "config.hex" is used to auto-generate cyfitter_cfg().

Where can I find more info about "config.hex"? In my ideal world, I'd like to use a "config.hex" to configure a PSoC 5LP in runtime.

Thanks.

[ricardoquesada]

[UPDATE: Replaced  EEPROM with "Flash ECC bytes"]

IIUC, the "config.hex" gets "copied" to the "Flash ECC"  (region 0x4800_0000), and then cyfitter_cfg() reads from it to program the UDB blocks.

Besides that, is there more info about the format of config.hex?

I'm not talking about the Intel Hex file format, but what's the meaning of each byte in the ".Flash ECC" region

Thanks!

[ricardoquesada]

In other words, is there a "schema" file for the data contained in "config.hex"?

I guess I can infer the schema by looking at cyfitter_cfg.c file, but perhaps there is an easier way to infer/know the schema? thanks!

[Len_CONSULTRON]

ricardo,

I don't know if config.hex is associated with the UDB.  It would appear not.

However, virtually all UDB control is obtained by writing to the appropriate register.

These registers normally get loaded before main() is executed.

It should be possible to modify the UDB registers at run-time.  However caution should be exercised.

Since these registers are on the 16-bit bus of PHUB, you can only modify 2 registers (2-bytes) at aa time.  A complicated UDB configuration means that you would partially configure the needed UDB block that might cause improper logic functions.

at a minimum, to avoid this perform the following steps:

• Turn off the source clock to the UDB blocks.  This would prevent clocking partially configured blocks.
• If there are a number of contiguous blocks of UDB registers to configure, use the DMA.
• Turn the source clocks back on.

Depending on your UDB logic in your design, these steps may not be enough.

Another problem is that at design-time, you don't have normally have access to the API calls for the UDB-based components.  You may have to create your own.

I brought up this kind of idea with Cypress many years ago.  The PSoC1 had the ability to use multiple configurations of their UDB-like and analog resources.  With PSoC Designer, you could define different configurations and there were API calls to load the new configuration at run-time.

The PSoC1 resources although good were not as sophisticated as found on the PSoC3 and PSoC5.  Cypress took my idea under consideration.

Your best bet is that if your UDB configuration function between configurations are minor.

In this case, with the UDB Editor, you can create your own custom component with multiple identiies.  Sort of like a "Swiss Army Knife".

Good luck!

[ricardoquesada]

Thanks for the info Len.

But I confirm that the autogenerated "config.hex" is indeed used to configure the UDB blocks.

The test that I did was:

Dump the data located at from 0x4800_0000 to x04800_2000 (the _ is used to make the numbers easier to ready).

And that data is exactly the same as the one in the config.hex file.

And, cyfitter_cfg() reads the data from 0x4800_0000 to configure the UBDs.

Regarding using DMA, I read somewhere (I had to remember where), it seems that it is faster to use a regular memcpy() than DMA in PSoC 5... but on PSoC 3 DMA is preferred.

thanks

[Ekta_N · Accepted solution]

Hello @ricardoquesada 

Config.hex is just a temporary file used for combining the final project HEX file, it is only generated by Creator when the ECC feature is disabled and "Store Configuration Data in ECC Memory" is enabled.
This file only contains the system configuration data which will be stored in ECC memory space, it doesn't have a complete HEX file format.

The config.hex file will not be generated in case you disable the "Store configuration data in ECC Memory " from the Systems thab in the design wide resources.

The section that you mentioned in the Cyfitter_cfg file will also disappear in this case.

If you refer to the PSoC 5LP Memory map section from the Architecture TRM, then the following table shows  that the UDB configurations are stored from 0x4000 6400 – 0x4000 6FFF:

Thus, for the purpose of making runtime configurations in the UDB, I suggest you follow Len's suggestions.

Best Regards
Ekta

[ricardoquesada]

aha! Thanks! 

When "store config in ECC" is disabled, then the data is put in cyfitter_cfg.c  in different arrays/structs; and that is what I was looking for... a kind of "schema" of the Configuration Data.

Thanks Len & Ekta!