CYBLE-022001 Flash and RAM

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

cross mob
Anonymous
Not applicable

We are planning to use the CYBLE-022001 (or CYBLE-022005) on several products.

   

1) Given that the CYBLE-022001 has 128kB of flash, how is this flash organized? What is the number of rows? We need this information to do firmware updates from a simple function in RAM.

   

2) Can we place UART Rx FIFO not empty and Tx FIFO empty ISR's in RAM to accomplish (1) above?

0 Likes
13 Replies
Anonymous
Not applicable

1) Managed to find a datasheet for PRoC mentioning in a side-note that the row (or block) size is 128 bytes.

   

 

   

2) Does it work if we define our own ISR Handler for UART and place that into RAM using the __attribute__ define?

0 Likes
Anonymous
Not applicable

We notice that the .hex files generated (in both Debug and Release profiles) for most of our projects are about 283 kB in size. However, the CYBLE-022001 has internal flash of only 128 kB. What is the format of this .hex file, and how much is being actually written to internal flash?

   

I am trying to do a firmware update of the CYBLE-022001, and need to understand which flash location to start writing from.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

It is intel hex format, quite common and user readable.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

I've also created a MyCase for this, but meanwhile do you know of any examples for firmware update of bootloadable image from bootloader? Our application has the CYBLE-022001 connected via UART to a larger microcontroller.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

You will need to program something like the "Bootloader Host" program into your " larger microcontroller"

   

You probably can get specs and sources from Cypress. Create a support case: At top of this page select "Design Support -> Create a Support Case" and describe your problem.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Thanks for the response Bob. We want to use our own protocol to update the firmware. What I'm not sure of is what physical address the bootloadable image actually starts at.

   

Here's what I'm at right now:

   

- bootloader project waits for special character before jumping to bootloadable

   

- bootloadable waits for special command sequence before jumping back to bootloader

   

 

   

However, after the bootloadable runs the bootloader, the bootloader isn't able to jump to the bootloadable a second time. Something gets messed up. To jump to the bootloader from the bootloadable, I am only calling:

   

Bootloadable_Load();

   

and nothing else. Is there something else that needs to be done, like stopping certain clocks or peripherals etc., before running the bootloader?

   

 

   

I have created a technical support case but do not have much response yet. Will wait.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

- bootloader project waits for special character before jumping to bootloadable

   

- bootloadable waits for special command sequence before jumping back to bootloader

   

This is not what bootloading is supposed to do:

   

Bootloader project waits for a special character to start the bootloading process else the bootloadable is executed)

   

bootloadable calls bootloader only with API Bootloadable_Load()

   

The bootloader trick is: in a variable is stored the information which program has to run after a device reset has been performed. After the successful bootloading of a project a reset is issued and the (newly) bootloadable gets executed.

   

For the start of bootloadable project refer to "Metadata Memory Map" in  datasheet.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Thanks Bob for the insight. I have worked around that issue by invoking a XRES reset instead of trying to do the above. Would you also know how to convert the .hex files produced by PSoC Creator to .bin files that we can directly write to the flash to update a bootloadable?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Would you also know how to convert the .hex files produced by PSoC Creator to .bin files Ask Mrs. Wiki Pedia

   

 

   

Bob

0 Likes
Anonymous
Not applicable

I assumed the tools would be target-platform-dependent, so thought someone here might have done such a thing. I'll see if there's source available for what PSoC Creator does internally. Thanks Bob.

0 Likes
Anonymous
Not applicable

The free tools I tried (e.g. hex2bin) just created an empty file, so I was wondering if Cypress did something different with the hex files. Will keep trying.

0 Likes
Anonymous
Not applicable

The .cyacd file format description is all one needs to create a utility that parses the file to extract the actual binary image of the bootloadable from it.

0 Likes
Anonymous
Not applicable

Hi

I'm doing something similar.

My base project is this one:

http://www.cypress.com/file/228556/download

(BLE External Memory Bootloader and Bootloadable Example Projects)

I've removed the BLE part from it because I don't have this devkit and want to just write the contents of cyacd file in usable format to eeprom.

But I'm having hard time to find anything that would help me to understand how to parse contents of cyacd file.

The first row of my cyacd (after header) is:

:00003F008000200020911F00009D2100009D21000010B5024B83F3088800F008F90020002010B51222184B1A6000F082FA174800F047FB042000F032FA00F0B8F9144A154B1A60154C8023DB052360063A134B1A600022134B1A601349072000F07DF9072000F06EF9104B2360802212030F4B1A600E4B1B681B03FBD4802252020B4B1A60C8

I've made an understanding that this is metadata information. But can anyone help me how to store this line into eeprom.

So, that when following code runs then it gets correct information from eeprom

reference_code_snippet.PNG

Thanks in advance

0 Likes