- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi.
I have a dual-cpu design, based on one of the Cypress/Infineon example projects and document AN215656. I now need to implement DFU, but all the available examples assume a single CPU design. Since both dual-CPU and DFU are largely based on linker-script magic, this makes for a difficult situation.
Is there any additional guidance - example projects or documentation - on how to go about this? Or has anyone had experience doing this? All help will be greatly appreciated, as I'm not looking forward to navigating this minefield on my own.
Thanks,
-Nick
Solved! Go to Solution.
- Labels:
-
PSoC 6 MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
DFU signing and verification expects application to be contiguous in the memory. Best option is to customize your application memory map to be contiguous.
However, if this is mandatory for your use case to use non-contiguous memory, I would recommend to break each discrete block to a separate application.
DFU can treat each of these blocks as individual application, sign and verify them independently.
There are no direct code examples to demonstrate this yet. You can refer CE221984 for understanding how multiple application can be placed, signed and verified and later customize to meet your requirements.
Thanks,
Krupashankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Poking to prevent this question from being ignored to death.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
Can you please share the details of your MCU and IDE?
Please refer to the below document where you can find code example and development guide for PSoC 6 Dual -CPU
AN213924 - PSoC 6 MCU Device Firmware Update Software Development Kit Guide.pdf
Please let us know if you need further details.
Thanks,
Krupashankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Krupashankar.
Thanks for the reply. I should have mentioned that my project uses ModusToolbox, not PSoC Creator. AN213924 assumes the use of the latter.
Is there a similar treatment for MTB?
Thanks again,
-Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
Please refer to MTB code example CE225604 (ModusToolbox).zip
Please refer to document CE213903 (ModusToolbox).pdf for creating DFU code for MTB.
Please find other DFU related examples and documents in below link:
Thanks,
Krupashankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
Sorry we don't have a ready to use example.
But you can take Dual- CPU design, integrate to perform DFU on CM0 and CM4.
DFU can run either on CM0 or CM4 at a given point of time.
Thanks,
Krupashankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Krupashankar.
Unfortunately, that's not much help. I created a dual-CPU DFU loader, but writing to flash from the CM4 fails, and seems to corrupt memory, presumably because the CM0+ is not in the correct state. PDL documentation doesn't discuss the matter, except to say that the CM4 must be either enabled or disabled. The implication is that only the CM0+ can write to flash, despite the fact that the DFU loader example writes to flash using the CM4.
What are the requirements for writing to flash from the CM4 in a dual-CPU application?
Thanks,
-Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are the requirements not documented anywhere?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
Please refer to link - https://infineon.github.io/psoc6pdl/pdl_api_reference_manual/html/group__group__flash.html
This gives the requirements and steps to write into flash memory using PDL.
Thanks,
Krupashankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Krupashankar.
Thanks, I'm already past that hurdle. Now the questions are all about linker scripts and cymcuelftool.
The CyMCUElfTool 1.0 User Guide suggests that I should define linker symbols __cy_memory_N_* to match the CM0+ and CM4 portions of the flash, but the linker scripts provided with the DFU example code use __cy_memory_0_* to define all of flash memory. Do I change __cy_memory_0_* to match, for instance, my CM0+ region, and add new (e.g. __cy_memory_5_*) symbols to match the CM4 region?
Do both parts have to have the same application ID, or must they have different IDs? Will they occupy one or two entries in the application metadata table?
The DFU API assumes that the application being loaded will have symbols __cy_app_verify_start and __cy_app_verify_length defined as the start and length of a single flash region, as well as the application entry point.
How does an application that includes two flash regions get verified? Will the API verify each region independently, or do I have to treat both as a single, continuous region? If the latter, won't the file CRC fail to match the calculated CRC?
Does the DFU API even work in that case?
Same question for the DFU Host Tool - will it correctly handle a .cyacd2 file that defines more than a single flash region?
Answers to those questions would be a big help.
Thanks,
-Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just keeping the thread alive...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NiBu_4687336 ,
DFU signing and verification expects application to be contiguous in the memory. Best option is to customize your application memory map to be contiguous.
However, if this is mandatory for your use case to use non-contiguous memory, I would recommend to break each discrete block to a separate application.
DFU can treat each of these blocks as individual application, sign and verify them independently.
There are no direct code examples to demonstrate this yet. You can refer CE221984 for understanding how multiple application can be placed, signed and verified and later customize to meet your requirements.
Thanks,
Krupashankar