How do I create a custom UDB solution in the Modus toolbox?

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

cross mob
NiBu_1198441
Level 2
Level 2
5 replies posted 5 questions asked First question asked

In PSoC Creator you could create a state machine/custom UDB block. Is there a way to do this in Modus Toolbox?

0 Likes
1 Solution

I've ported a UART Component from PSoC Creator to Modus and I can confirm it works.

  1. First step is enabling the UART Component for PSoC6 in PSoC Creator (import and edit component.cystate, set to prototype or production)
  2. Second, design your schematic in PSoC Creator and build
  3. Copy cydevice.trm, cyfitter.h, project.h, cyfitter_cfg.c and .h to a folder inside your Modus project and include
  4. Change the function name Cy_SystemInit inside cyfitter_cfg.c to Cy_UDBInit();
  5. and take everything out before: ClockInit();
  6. The function ClockInit(): take everything out before: /* Configure peripheral clock dividers */
  7. The remaining will be configuration of the UDBs, the IO's and the Peripheral clocks to the UDB.
  8. Copy the component API from Creator to a new source subfolder in Modus (something like ComponentAPI/).
  9. In the main source file call the new function UDBInit() and it works!

Schermafbeelding 2019-06-07 om 17.34.31.png

View solution in original post

36 Replies
Ekta_N
Moderator
Moderator
Moderator
750 replies posted First like given 250 solutions authored

Hello,

ModusToolbox currently does not support UDB's.

0 Likes

If I create a Component in PSoC Creator, how to I integrate it into a Modus project?

0 Likes
Ekta_N
Moderator
Moderator
Moderator
750 replies posted First like given 250 solutions authored

Hello,

Can you tell which PSoC device you are using? Some the the PSoC 6 devices are supported by creator. In that case you could use Creator for creating the component and the project.

Regards

Ekta

I just received the CY8C624ABZI-D44 from the CY8CPROTO-062-4343W kit. This is a PSOC6 part.

I took the SRAM component and added some control logic to run it in a custom mode. This was proven on a PSOC5LP chip. I'd like to use the AES-256 cryptography in the PSOC6 to stream data between the SRAM and SPI. The custom logic lengthens the CE and WE pins to match the external memory interface. I rely on DMA to stream data quickly through the PSOC5LP.

I only expect to need to write code on the PSOC6 to setup the AES-256 module. My code needs are minimal. So really, I want a PSoC Creator that fully supports the CY8CMOD-062-4343W.

Yeah, your custom control logic is probably implemented in a UDB PLD.  Depending on what you're doing, it *may* be possible to run those signals through the TCPWM to extend them, but that relies heavily on your system and the requirements.

0 Likes

So let's be clear, Modus Toolbox only supports PSoC 6.  If you make a component for any other device, there's no way to move it to Modus Toolbox.

Also, if your component uses UDB resources (datapath, PLD logic, status, control, sync, etc) again you will not be able to port your component to Modus Toolbox.

If you have a strictly software component, it should be trivial to port your component.  Generate your code in Creator, copy the generated code to your Modus Toolbox project and call your APIs.

If you have a component using fixed function blocks and software, you can do something similar, but you will need to convert instance based calls to PDL based calls.

0 Likes

ScottA_91 schreef:

Also, if your component uses UDB resources (datapath, PLD logic, status, control, sync, etc) again you will not be able to port your component to Modus Toolbox.

I don’t see why this won’t work. As long as the UDB configuration registers (at 0x4034xxx)  are initialized correctly, UDB blocks will work in Modus as well.

0 Likes

I've ported a UART Component from PSoC Creator to Modus and I can confirm it works.

  1. First step is enabling the UART Component for PSoC6 in PSoC Creator (import and edit component.cystate, set to prototype or production)
  2. Second, design your schematic in PSoC Creator and build
  3. Copy cydevice.trm, cyfitter.h, project.h, cyfitter_cfg.c and .h to a folder inside your Modus project and include
  4. Change the function name Cy_SystemInit inside cyfitter_cfg.c to Cy_UDBInit();
  5. and take everything out before: ClockInit();
  6. The function ClockInit(): take everything out before: /* Configure peripheral clock dividers */
  7. The remaining will be configuration of the UDBs, the IO's and the Peripheral clocks to the UDB.
  8. Copy the component API from Creator to a new source subfolder in Modus (something like ComponentAPI/).
  9. In the main source file call the new function UDBInit() and it works!

Schermafbeelding 2019-06-07 om 17.34.31.png

Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

And even created a tool to automate UDB import in Modus (or any other tool)....

Tested with PSoC6 UART UDB + API

PSoC Rocks again!! 

Schermafbeelding 2019-06-12 om 00.53.14.png

This is great news!  I will share with our FAE and regional marketing teams within Cypress.

Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

Feel free to use this tool or contribute code.

Link

Rolf,

I started a blog about enhancing your great program to address UDB deficiencies in PSoC6 and MTB.

I'm hoping to address some issues to make it more full-featured by including components and initializing as many system resources as possible.  Right now, your code only initializes the clock dividers attached to the CLK_Peri clock.  This requires that all the system resources in the Creator design matches the MTB design.

https://community.cypress.com/blog/update-post.jspa?ID=1864&draftID=152689

Len

PS:  Great work!

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Len,

Thanks for helping making the tool better! The link you provided isn't accessible (unauthorized).

Looking forward to see your info.

Rolf

0 Likes

Rolf,

I placed the blog in "Problem Solvers" forum.  I think it might be a "closed" forum.  Although I thought your name was listed somewhere as invited to join this forum.

I tried your UDB_port tool again.   It didn't find the components and port the APIs to the destination UDBconfig directory.  Maybe I missed a configuration parameter when I ran UDB_port?

Len

Update:

I tried UDB_port on another PSoC6 project.  This time the API calls to the CapSense component were added to the UDBconfig directory.

Hmmm...  What decisions are you making about whether or not to include components?   For example:  In the project with the included CapSense component there at least:

  • A PDL timer
  • A PDL SCB as SPIM
  • 8 PDL LEDs

It would be theoretically advantageous to include the API calls for all these additional components since the original PSoC Creator code being ported makes references to some of the calls and global variables and defines.

Also, the previous project I mentioned where no components there were included there were:

  • A PDL SCB as UART
  • 1 PDL LED
  • 2 non-PDL components with no UDB structure.  Mostly lib code in component form.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

The tool loads the projectname.svd file and extracts the used components from the XML file (see the source code which is freely available at github):

Schermafbeelding 2020-04-11 om 17.30.24.png

I didn't see any problems with this earlier. Do you have an example where the component APIs are not copied?

Normally all components should be copied and the global references and references should be included in the corresponding API header files which are referred to at project.h

0 Likes

Rolf,

The PSoC6 project I was porting to MTB is located as an attachment in the link: Terminal Support Component Library

The PSoC6 project is just one of the projects in the workspace bundle.  You can delete all of the projects except:

  • String_Funcs_Demo_PSoC6-063-BLE (The project I'm porting)
  • CONSULTRONLib (String_Funcs, MenuCmds and Term custom components used in the projects)

You might find the String_Funcs and MenuCmds component/lib useful if you're trying to quickly put together some "quick" Terminal-based user interfaces.

I've got to check out the XML code you've mentioned.

Here's the crux of my idea:

MTB has virtually (or absolutely) no support for UDBs.  Even for those PSoCs that are blessed with UDB blocks.

It would be great if I can create the project with Creator making use of the TopDesign with access to UDB and analog routing available on the part.  The TopDesign schematic approach also allows for better visually connections. 

The MTB's Device Configuration tool forces you to plod through multiple tabs.  It's 'doable' but not as intuitive.

Your UDB_port tool works very well on converting the UDB routing structure to data that can be loaded.

The next step is to take the Creator DWR structure (I believe most of it is found in <project>.cydwr file).   This is an XML file and convert it to the MTB equivalent which is mostly found in the design.modus of the libs directory under the chosen BSP.  This is another XML file.

Sadly the two XML files use different naming assignments.

I'm wondering if there is a tool to convert one XML to another XML with field/parameter name conversions?  I think I heard a while back ago about someone using Microsoft Access to create a database of field/parameter equivalences.  If the database approach works, it might be easier to update field/parameters naming for new or updated components.

Ultimately, it might be possible to unlink the TopDesign creation/generation tool from Creator and use it in place of MTB's Device Configuration tool.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

Thanks for your detailed feedback and your work on the nice library you created. I'll check out the library with the UDB_port tool and give feedback.

Regarding the interoperability between the Creator DWR / schematic editor and the MTB's device configurator (and converting the XML file), I think this will be a though route to go (if even possible).

I do not see any advantage of using MTB's device configurator over using PSoC Creator DWR / schematic editor. In fact the UDB_port tool converts the complete configuration (including the DWR setup) to a single bundle to use inside MTB. So the use of the device configurator would make no sense when it can be done with the much more flexible and intuitive Creator tools. The disadvantage is that the Creator tools only runs on Windows. Maybe the tool should be renamed to "Creator configuration bundler' or something.

I also asked Cypress if they like to publish the Creator's source code in order to strip out the DWR / schematic designer into a single tool to use with MTB directly. Unfortunately I never got a reply.

Anyway, if you still see advantages of using MTB's device configurator together with the Creator DWR/schematic editor, can you elaborate me?

0 Likes

Rolf,

I'm in agreement with you.  The ONLY advantage of MTB's Device Configurator is that it can work on Mac or Linux.   That's probably why Cypress is resisting porting the Creator DWR tools to MTB ... too much work.

The advantage of a DWR to Device Configurator conversion is that the analog routing and System clock setup and some System resources can be initialized before main() is executed.  (Wouldn't it be nice if your UDBinit() can be executed before main() too!) I noticed that your UDB_port tools configures the Peripheral Clocks by not the System Clocks or Analog routing.   Right now with your tool I need to manually pre-set the MTB analog and System clock resources to match the Creator's DWR configuration.  

My first attempt to use your UDP_port didn't work right away.  This is because the Creator DWR System clocks were different than the default setting for the MTB System Clocks.  A little HW debugging and I found the clock sources to the UDB blocks were off by a factor of two.  I found the DWR and MTB System clock divisor discrepancy and readjusted the MTB setting and viola!   It worked!  Maybe I'm missing something and got it wrong.

As to the question about Creator tied to the Windows environment.  Oh well...  Of the 38 years as a professional engineer in the design field, 99% of my engineering design work would only run on a DOS or Windows platform. C'est la vie.

I wanted to thank you for your hard work on UDB_port as well as your PSoC support on the forums.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Len,

because the Creator DWR System clocks were different than the default setting

I notice, I deliberately stripped out the Clocks setup. Not sure why I did this, I guess initially I start to use it with MTB device configurator as well. If you have Visual Studio, you might want to strip out these lines:

Schermafbeelding 2020-04-11 om 22.03.12.png

Wouldn't it be nice if your UDBinit() can be executed before main() too!

Yes, that's possible! Notice this in the startup assembly file:

Schermafbeelding 2020-04-11 om 21.59.26.png

If __NO_SYSTEM_INIT is not defined in MTB, it would jump to SystemInit(); If you'd replace it with UDBInit(); then it would initialize before starting. You even might want to strip out the renaming of the function Cy_SystemInit(); to UDBInit(); in Visual Studio.

And yes, I used to work a lot on DOS/Windows as well (not 38 years but close!). Nowadays I'm migrating more and more to MAC as I really like the solid hardware and the (older) MAC Pro's are easy upgradable to 12 Cores with a bunch of memory. This setup is lightning fast for compilers which runs on multiple cores simultaneously.

Anyway, maybe it's a good idea to put the Visual Studio project on github directly, so multiple people can ellaborate on the project.

Regards,

Rolf

0 Likes

Rolf,

We both think that the DWR especially the TopDesign segment is a better tool than MTB's Device Configurator.  However, the DWR tool is only Windows-friendly.

If the biggest hurdle to converting the DWR to non-Windows platforms is the schematic-entry, then this may be solvable.

Many schematic entry tools that create a netlist as an output.  If this netlist (text file) can be parsed for interconnection validation for the Application Build phase then schematic entry may not be the biggest problem to solve.  The netlist parsing utility theoretically doesn't need a GUI.  It can be run in the background from a CLI launch.

An example of a schematic entry program I used quite frequently is LTSpice XVII.  It is from Analog Devices (formerly Linear Tech).  It can run on Windows, MAC and Linux.  Here's another bonus:  It free!

Additionally LTSpice is designed to simulate HW as a PSpice program.  This could be an additional benefit to pre-validate the UDB(, Verilog or even Analog) design before committing it to the PSoC!   Right now, the Creator validates UDB timing for setup and hold times.  Does the MTB do that?

Another advantage of the TopDesign segment is that it allowed users to add external elements into the schematic.  Not only did this provide a visual connection those critical elements OUTSIDE the PSoC but it showed the relationship.  This feature allows me to share the design with others for improved reviews and understanding of the contribution the PSoC provided to the design.   Note: Some external components contain a parameter called "Spice_Model".  It was intended for future use. Hmmm...

From the first PSoC device I designed with (PSoC1) in 2002, I was impressed with Cypress' commitment to thinking outside the CPU box with innovative solutions.  Back then they had early version of the UDB and Analog SCBs (Switched Capacitor Blocks).

They've improved their CPU portfolio as well as the eco-systems to design with.  It started with the "Designer" then to the "Express" which eventually became the "Creator".

Wow!  I think we just turned this discussion into a blog!

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Len,

Many schematic entry tools that create a netlist as an output.

Yes, not sure if Creator creates/uses a netlist (seems like, as you can see the net numbers in the Analog DWR view). Along with the verilog (I guess they call their Verilog compiler WARP) and the component customizer the configuration and APIs are generated.

It would be nice for sure if Cypress could migrate the DWR for ModusToolbox (either with or without schematic editor and netlist instead).

Some external components contain a parameter called "Spice_Model".  It was intended for future use.

Yes, PSoC Creator is incredibly full featured and I was always amazed bij how much features were 'under the hood' of the tool. Even the datapath editor and the way components can be edited is peerless (I'm sure some people at Cypress are smiling right now 😉 ).

I started to work with PSoC1 as well and was very impressed as well about the innovative chip. I never got it why their PSoCs didn't gain more traction, probably because they kept focussing on high-volume customers and never put effort in making it more 'mainstream'. Also the extensive range of tools and kits always have been very good.

I am still worried Cypress is phasing out UDB's and that would be worst thing what could happen to PSoC imho (it would then be like any other mcu and loose a lot of the functionality why one choose PSoC over any other).

Hope Cypress at least spend a few days to migrate a bunch of UDBs for PSoC6, that wouldn't cost a lot of time and add a lot of functionality and flexibility.

And yes, it's more becoming a blog. Maybe we should start a PSoC enthousiast group and push Cypress to support UDBs again!

Rolf,

I am still worried Cypress is phasing out UDB's and that would be worst thing what could happen to PSoC imho (it would then be like any other mcu and loose a lot of the functionality why one choose PSoC over any other).

According to a Field rep for Cypress I spoke to, this appears to be the direction.

It is my understanding that the reasoning behind this direction is that few designers using their product make use of all the UDB and routable analog features.

Even back in the PSoc1 days, Cypress was marketing that their PSoC products and features can help to reduce BoM costs.  For me, every time I used a PSoC CPU to it's fullest, I did just that. 

With their PSoC5 product, I was able to internalize 90% of the design and use just a few external caps and resistors and in one case an external power semiconductor.  In my 38+ years of HW design, I've used more than 20 CPUs.  Of all of them, the PSoC is the most versatile and innovative.

Most CPUs have dedicated internal peripherals with fixed functions.  This usually meant that if the IC manufacturer didn't conceive of your application:

  • The internal peripheral did not exist.
  • You have to make due with the internal peripheral(s) available usually with limited performance.  This is accomplished using SW instead of HW state machines.
  • You have to add external peripherals to achieve your design goals.

In my early designs, I used CPUs with address and data buses.  There were no internal peripherals. To accomplish anything with external peripherals you needed to design logic circuits using logic ICs like the 74LS, 74AS, TTL-series chips.  I thought it was fun to create my own HW state machines however it was a "pain" to wire everything up on a PCB.  When PLDs came out, I was thrilled.  That's why I like UDBs and WARP.  It gives me more control to optimize my design.

I could be wrong here, but I think the average designer is getting a little lazy.   Back in the "good ol' days", our CPUs ran at 1MHz.  You needed good HW state machines to achieve the customer's requirements.  Now, you can use 'weak' internal peripherals at 150MHz polling or interrupts to achieve very good performance.  However the PSoC with UDBs AND DMAs can provide exceptional performance and maybe even more importantly reduce the CPU overhead.

Maybe we should start a PSoC enthousiast group and push Cypress to support UDBs again!

I fully agree.  We should let the world know why the PSoC (with UDBs and routable analog of course) are the exceptional products.

In addition, we may need to start a forum in the Cypress community to help others understand the power of the PSoC architecture and instruct others on how to make use of this in their designs. 

With Infineon acquiring Cypress, I'm hoping we can enlighten the new management to what makes the PSoC a great architecture.  By helping them acquire more converts to the platform, it should make good business.

Len

Len
"Engineering is an Art. The Art of Compromise."

Len,

Even back in the PSoc1 days, Cypress was marketing that their PSoC products and features can help to reduce BoM costs.  For me, every time I used a PSoC CPU to it's fullest, I did just that.

Same for me. Almost every design I made with PSoC couldn't be done more effectively with another micro. PSoC always saved me a lot of time and the lower BOM cost was justifying not only the price of PSoC twice over, updates which normally required a h/w re-design could be done now in s/w.

Also routing the chip is extremely easy as you don't have to look up and route up to where the peripheral pins are located. Besides saving time, the board layout could be much simpler and probably one can even reduce the amount of layers (most layers are usually needed to accommodate the routing to the CPU). Cypress may strip out all 'fixed function blocks' to save cost and just implement UDBs which are versatile enough to cover peripheral functions like I2C, UART, SPI, SDI12 , OneWire, (Capture) Timer block, CAN, Manchester decoder, Quadrature decoder, Counter block, SmartIO, LFSR / CRC functionality, ShiftReg glitch filtering, State Machine functionality etc.

I remember using Microchip before using PSoC. Microchip was having a broad range of micros, varying from small devices with almost no peripherals,  devices with more IO's but lacking certain peripherals to devices with lots of memory and peripherals. I was always figuring out which one to use (no UART but I2C and PWM etc). Then when there was PSoC, just a few devices covered the functionality of all the different Microchips MCUs.

I know Cypress virtually used one silicon for a broad range of PSoCs which then in turn generated high volume and lower cost price for the broad range. They also did 'brand' PSoCs with dedicated functionality which were in fact just normal PSoCs like CY8CLED and EZ-Click.

As Cypress seems to be focussing on automotive a lot these days, I'm sure PSoCs with UDBs are perfect for lots of dedicated tasks and could be branded as speciality micros. For example, UDBs can be used for critical safety tasks  as there's no s/w / MCU involved.

This is an example where I used PSoC UDBs to the fullest: a 48 channel PWM with nanosecond accuracy for printing 'liquid food deposites'.  Foodjet chocolate printhead LQ - YouTube

With Infineon acquiring Cypress, I'm hoping we can enlighten the new management to what makes the PSoC a great architecture.  By helping them acquire more converts to the platform, it should make good business.

Fully agree. Let's see if we can get traction going!

Best,

Rolf

Rolf,

Amen Brother!

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

UDBs and analog routing are the reason why I've stuck with PSoC even though it's a more expensive chip in some cases: the per-unit cost is made up for by the integration, ease of use, and flexibility it offers me as a designer (not to mention the uniqueness of PSoC Creator!). The patents look like they're in place (depending on which one) for the next decade or so. If Infineon/Cypress does phase out UDBs, I hope someone licenses those patents to use them in their own chips (or that they sell at least some of the "before PSoC 6" families to another company). If not, in 2032 (presuming they're not abandoned earlier), someone could integrate them, or an upgraded version of them (I can think of some changes that would be great), into RISC-V based chips perhaps or as dedicated "configurable/programmable datapath" chips (in either case, the clock rates could probably be jacked up significantly).

0 Likes

Len,

Do you have the .svd file in your Creator project folder. I just noticed it's not always generated, this may explain why the subfolders are not copied.

Did you also try to modify the Visual Studio code?

Rolf

I believe that UDB-based PSoCs at Cypress are doomed; Cypress will concentrate on traditional-style uC due to economical and marketing reasons (not sure if they can be competitive in that). I see a possible solution as to sell the PSoC line to another company, who would be interested in that direction of development. Personally, I would like to see PSoC1 with upgraded M0 or M4 core and upgraded IDE.

/odissey1

I believe that UDB-based PSoCs at Cypress are doomed

I fear for that as well and that would be very sad. I have lots of continuously running projects which needs h/w upgrades once in a while. If these products can't be upgraded with 'UDB style' PSoCs, their BoM price will go up and then it's just a matter of choosing the uC with best value for money. Doubt as well if Cypress will be competitive.

Personally, I would like to see PSoC1 with upgraded M0 or M4 core and upgraded IDE.

Agree. The analog stuff in PSoC1 is amazing and it's a pity Cypress never implemented switch-cap into the latter versions. Willing to pay a few bucks more for a uC with switch-caps and UDBs and having an upgraded IDE.

I bet if Cypress realizes that their PSoCs are having a place in the market because of it's excellent configurability (analog / UDB).

Let's hope for the best!

Rolf,

I looked and there is no .svd file for the PSoC6 projects.

Here's a table of the project's included in the CONSULTRONLib archive.

Project Dir

Project Target PsoC-type

.SVD file found

MenuCmds_Demo.cydsn

PsoC5

Yes

String_Funcs_Demo.cydsn

PsoC5

Yes

String_Funcs_Demo_PSoC4-042-BLE.cydsn

PsoC4

Yes

String_Funcs_Demo_PSoC4-049_Bootload.cydsn

PsoC4

Yes

String_Funcs_Demo_PSoC4_148.cydsn

PsoC4

Yes

String_Funcs_Demo_PSoC6-062-BLE.cydsn

PsoC6

No

String_Funcs_Demo_PSoC6-063-BLE.cydsn

PsoC6

No

String_Funcs_Non_Term_Demo.cydsn

PsoC5

Yes

Term_Demo.cydsn

PsoC5

Yes

In each of the projects above, there are at least three major components in the TopDesign:

  • UART (or Term).
  • MenuCmds (my custom component).  This component doesn't use any digital or analog resources.  99% library API code.
  • String_Funcs (my custom component).  This component doesn't use any digital or analog resources.  99% library API code.

I used "String_Funcs_Demo_PSoC6-063-BLE.cydsn" to create my UDB_port.  In this case NO components were ported.

When I used "String_Funcs_Non_Term_Demo.cydsn" (PSoC5) only UART gets ports.

When I used "String_Funcs_Demo.cydsn" (PSoC5) no components are ported.  This project uses my substitute custom component for UART called "Term".  "Term" embeds the UART and USB_UART components.  Only one is enabled at a time.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

LePo_1062026​ , I'd like to read this but for me it says

"Unauthorized"

0 Likes

MiMi,

I assume you are referring to this link:   https://community.cypress.com/blog/update-post.jspa?ID=1864&draftID=185729

I loaded it into a restricted area.   Let me move it out if possible.

Len

Try this link instead:  Seeking Ideas -- PSoC Creator Project to ModusToolbox Project importing/conversion

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hi Everyone,

I have a related question, a bit off topic, but perhaps someone can answer it.

Can the same technique be used to import custom PSOC6 UDBs into MBed OS projects, or into Peripheral Driver Libraries to be used there?

Other question, is the blog pointed by the link above a "secret society" of sorts?, I'm getting an ACCESS DENIED message.

0 Likes

GuGa,

... is the blog pointed by the link above a "secret society" of sorts?

Ha. Ha!   Not really.  There are a few of us invite by Cypress to be non-employee "Problem Solvers".   When I placed the original post, I didn't realize that it was not viewable by Forum users.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
SaKrst
Level 3
Level 3
5 likes given First like received First like given

There's something that I'm missing here, but shouldn't CY8C62xA series be without UDB? At least that's what I found on this link https://www.cypress.com/documentation/datasheets/psoc-62-cy8c62x8-cy8c62xa-datasheet

UDB, 2MB of flash, and 1MB of SRAM with blue-tooth should be available from PsoC 64.

On CY8CPROTO-062-4343W is CY8C624ABZI-D44 that shouldn't have any UDB's.

0 Likes
Rolf_Nooteboom
Level 5
Level 5
10 sign-ins 5 solutions authored First solution authored

I made two components for PSoC6 available for the public: I2C component and the UART component (both UDB).

Route the UART or I2C to any IO you like!

https://forum.onethinx.com/t/how-to-use-udb-components-on-psoc6/365

Dear @Rolf_Nooteboom 

thanks for very comprehensive post. I get information that it only works with PSoCs that have internal UDBs and are recognised by PSoC Creator. What to do with PSoC6 which has >2MB flash, and it is not supported in PSoC Creator. Is here some another option ? It is strange that after several years of Modus Toolbox development there are still many not transferred functionalities.

Radim

 

0 Likes