DFU for Dual-CPU Design

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

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

0 Likes
1 Solution
Krupashankar
Moderator
Moderator
Moderator
500 replies posted 50 likes received 25 likes received

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

View solution in original post

0 Likes
12 Replies
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

Poking to prevent this question from being ignored to death.

0 Likes
Krupashankar
Moderator
Moderator
Moderator
500 replies posted 50 likes received 25 likes received

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

 

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

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

0 Likes

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:

https://www.cypress.com/documentation/code-examples/ce213903-psoc-6-mcu-basic-device-firmware-update...

 

Thanks,

Krupashankar

 

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted
 
[This duplicates the email I sent when the forum was down for maintenance]
 
I think you may have misunderstood my question. The process for creating a *simple* - CM4-only - DFU-loadable application is adequately documented. I understand the process, and have built and tested the example applications.
 
But my application includes a custom CM0+ application in addition to the more common CM4 application. I based the application on example mtb-example-psoc6-dual-cpu-empty-app and document AN215656. Now I need to make this application downloadable via DFU.
 
Building a dual-CPU application involves a specialized makefile and linker scripts for both the CM0+ and CM4 cores.
Building a DFU-loadable application involves specialized a specialized makefile and linker scripts as well. The makefile and linker scripts for either case are not compatible with the other.
 
Elements of the makefile and linker scripts from both cases need to be combined for the dual-CPU + DFU case.
 
All of the examples I have found, including those you have referenced, assume a single-CPU design, that is, a design using the pre-compiled "CM0_SLEEP" CM0+ code. These doesn't address my question. My question is about how to create a DFU-loadable, dual-CPU application. 
 
The MCU I'm targeting is the CY8CPROTO-063-BLE, using MTB 2.3.
 
Thanks,
 
-Nick
0 Likes
Krupashankar
Moderator
Moderator
Moderator
500 replies posted 50 likes received 25 likes received

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

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

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

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

Are the requirements not documented anywhere?

0 Likes

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

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

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

0 Likes
NiBu_4687336
Level 5
Level 5
5 solutions authored 50 replies posted 25 replies posted

Just keeping the thread alive...

0 Likes
Krupashankar
Moderator
Moderator
Moderator
500 replies posted 50 likes received 25 likes received

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

0 Likes