Hi J_K,

The same hex file can be programmed with Cypress IDE so the hex is valid.

It seems to us that the .hex file created by Cypress IDE contains (at address 0x9030 0000) the Checksum of the flash section , which is most likely used by Cypress IDE to verify the that the contents of the flash area and the data file are identical.
This address cannot be programmed, thus will J-Flash will fail to do so. According to the manual, this address is written to by the controller, and can be used for verification purposes.

J-Flash should only be used with data files that solely contain (programmable) flash addresses.


Best regards,
Niklas

Hi J_K,

maybe I was not clear enough:

The data (.hex) file created by Cypress IDE presumably contains
a) The data for the flash memory at 0x0 - 0x3FFF
and
b) The checksum at 0x9030 0000 - 0x9030 0001

If you tell J-Flash to download this data file to your target:
a) J-Flash will successfully program the flash memory.
b) J-Flash notices that it can not write to 0x9030 0000 and reports an error.

The solution is to provide J-Flash with a data file that solely contains data at flash addresses.
0x9030 0000 - 0x9030 0001 is written to by the controller and should only be read, but not be written to.
Furthermore, it is not a flash address. E.g. providing a .hex file containing RAM addresses would also result in an error, although JLink can write data to RAM .


Best regards,
Niklas

Hi All,

Is there any way to work-around this from your experience? Any other users encountering the same issue before?

i am experiencing the same issue with the CYBLE-022001-00 module.
The only workaround I found is to manually delete the metadata-section in the *.hex file.
Of course this is a little bit annoying.

J-Flash should only be used with data files that solely contain (programmable) flash addresses.

I can somehow understand this point.
But in my opinion, a progamming tool should be able to handle Hex-files as they are produced by the toolchain.
It would be nice if J-Flash could handle the Hex-file in the format it is originally created by PSoC-Creater.
Maybe by just ignoring the additional information (after a warning message or something like that).
Editing/processing Hex-files after compilation is not a desirable point in the workflow.

The metadata section also contains data for the Flash Protection mechanism and the chip level protection used by Cypress.
Currently this can only be used by Cypress tools (MiniProg, PSoC-Programmer, etc.), as far as I know. Is it possible, that J-Flash could also do this in the near future?

Best regards,
Martin

Hi all,

as Niklas already wrote:
a) J-Flash is a utility to program the internal flash
b) The output from Cypress IDE contains data which can not be programmed and therefore they should not be included in the data file to be programmed

But in my opinion, a progamming tool should be able to handle Hex-files as they are produced by the toolchain.

Of course we could implement the functionality in J-Flash to be able to ignore or to use the values in this area but this is not an option because there is no way to implement this in some kind of generic way. As we support a width range of tool chains we can not take care of every special data file format which has been created by a toolchain. Think about another tool-chain saves some other meta data in the same section which needs to be interpreted in another way.

Maybe by just ignoring the additional information (after a warning message or something like that).

We have already planned for future versions of J-Flash, to implement a feature which allows to mask out areas in the data file.

Editing/processing Hex-files after compilation is not a desirable point in the workflow.

As described above, the problem is not J-Flash but that PSoC-Creator creates a "data file" which basically is not valid for this device as it includes areas which can not be programmed. Anyhow, you can automatically delete this area by using the command line arguments of J-Flash and therefore this does not waste any time as the time for deleting is almost zero.

The metadata section also contains data for the Flash Protection mechanism and the chip level protection used by Cypress.

The flash protection / any custom sequences, which are different from device to device as well as from user to user, can be specified in the J-Flash project "Exit steps". They are under full user control and therefore users can execute whatever they need.


Best regards
Erik

I share the same opinion with Martin here - since this device is listed as supported by J-Flash, most users would expect it to work with the hex files primarily created by PSoC Creator.

We got this point from a user who is working with PSoC Creator but as described before: J-Flash is a universal tool which supports a wide range of devices as well as IDEs, etc... Considering this fact, there is no generic way how to implement this. If for example another IDE / PC Utility creates a binary for the same device with other data in this area, there would no opportunity for J-Flash to determine if the file should be handled as "created from PSoC Creator" or as "created from another third party utility". Furthermore, J-Flash supports almost 5000 devices right now where each device may have a different special areas, special handling, special functionality, etc. Unfortunately, it is impossible to support / take care of all theses device specifics in such an universal tool as some features / areas may be interact with other devices.

However, I will try to prioritize the "mask out areas" feature so it may be available soon.
For now, please use the -delrange command line (see example below)

JFlash.exe -openprj"C:\Work\SampleProject.jflash" -open"C:\Work\PSocOutput.hex" -delrange0x90300000,0x90300001 -auto


Best regards
Erik