- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is intel hex format, quite common and user readable.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would you also know how to convert the .hex files produced by PSoC Creator to .bin files Ask Mrs. Wiki Pedia
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Thanks in advance