[][src]Struct debug_probe::flash::loader::FlashLoader

pub struct FlashLoader<'a, 'b> { /* fields omitted */ }

Handles high level programming of raw binary data to flash.

If you need file programming, either binary files or other formats, please see the FileProgrammer class.

This manager provides a simple interface to programming flash that may cross flash region boundaries. To use it, create an instance and pass in the session object. Then call add_data() for each chunk of binary data you need to write. When all data is added, call the commit() method to write everything to flash. You may reuse a single FlashLoader instance for multiple add-commit sequences.

When programming across multiple regions, progress reports are combined so that only a one progress output is reported. Similarly, the programming performance report for each region is suppresed and a combined report is logged.

Internally, FlashBuilder is used to optimize programming within each memory region.

Methods

impl<'a, 'b> FlashLoader<'a, 'b>[src]

pub fn new(
    memory_map: &'a Vec<MemoryRegion>,
    smart_flash: bool,
    trust_crc: bool,
    keep_unwritten: bool
) -> Self
[src]

pub fn add_data(
    &mut self,
    address: u32,
    data: &'b [u8]
) -> Result<(), FlashLoaderError>
[src]

Add a chunk of data to be programmed.

The data may cross flash memory region boundaries, as long as the regions are contiguous. address is the address where the first byte of data is located. data is an iterator of u8 bytes to be written at given address and onwards.

pub fn get_region_for_address(
    memory_map: &Vec<MemoryRegion>,
    address: u32
) -> Option<&MemoryRegion>
[src]

pub fn commit(&mut self, session: &mut Session)[src]

Write all collected data to flash. This routine ensures that chip erase is only used once if either the auto mode or chip erase mode are used. As an example, if two regions are to be written to and True was passed to the constructor for chip_erase (or if the session option was set), then only the first region will actually use chip erase. The second region will be forced to use sector erase. This will not result in extra erasing, as sector erase always verifies whether the sectors are already erased. This will, of course, also work correctly if the flash algorithm for the first region doesn't actually erase the entire chip (all regions). After calling this method, the loader instance can be reused to program more data.

Auto Trait Implementations

impl<'a, 'b> Send for FlashLoader<'a, 'b>

impl<'a, 'b> Unpin for FlashLoader<'a, 'b>

impl<'a, 'b> Sync for FlashLoader<'a, 'b>

impl<'a, 'b> UnwindSafe for FlashLoader<'a, 'b>

impl<'a, 'b> RefUnwindSafe for FlashLoader<'a, 'b>

Blanket Implementations

impl<T, U> Into<U> for T where
    U: From<T>, 
[src]

impl<T> From<T> for T[src]

impl<T, U> TryFrom<U> for T where
    U: Into<T>, 
[src]

type Error = Infallible

The type returned in the event of a conversion error.

impl<T, U> TryInto<U> for T where
    U: TryFrom<T>, 
[src]

type Error = <U as TryFrom<T>>::Error

The type returned in the event of a conversion error.

impl<T> BorrowMut<T> for T where
    T: ?Sized
[src]

impl<T> Borrow<T> for T where
    T: ?Sized
[src]

impl<T> Any for T where
    T: 'static + ?Sized
[src]