.cproject

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
SW update HD test

  1. … 5 more files in changeset.
Why is bootloader executing in a different mode than app? Is that necessary? How will mode switch back to user when jumping to app?

Why is bootloader executing in a different mode than app? Is that necessary? How will mode switch back to user when jumping to app?

Bootloader seems to be executed in supervisory mode. if so, the current allocated stack for supervisory mode is 1K (if we merge into existing HD/DG firmware). we may need to watch for supervisory m...

Bootloader seems to be executed in supervisory mode. if so, the current allocated stack for supervisory mode is 1K (if we merge into existing HD/DG firmware). we may need to watch for supervisory mode stack size, in case boot loader consumes more that 1K?

the second value is 0x00 or 0xFFFFFFFF? The bootloader checks the value is not equal to 0xFFFFFFFF, if so, the valid application is not found, and firmware needs to be updated.

the second value is 0x00 or 0xFFFFFFFF?

The bootloader checks the value is not equal to 0xFFFFFFFF, if so, the valid application is not found, and firmware needs to be updated.

Looks to be memory overflow to be occurred. src-> pointing the buffer of 4 bytes length. bytes-> mentioning 16 bytes length. g_pulUpdateSuccess[] should be allocated more than the current size. Als...

Looks to be memory overflow to be occurred. src-> pointing the buffer of 4 bytes length. bytes-> mentioning 16 bytes length. g_pulUpdateSuccess[] should be allocated more than the current size. Also, Do we need to typecast "(uint32_t) bytes", since the api mentioning (uint8_t)?

Fapi_StatusType Fapi_issueProgrammingCommand(
uint32_t *pu32StartAddress,
uint8_t *pu8DataBuffer,
uint8_t u8DataBufferSizeInBytes,
uint8_t *pu8EccBuffer,
uint8_t u8EccBufferSizeInBytes,
Fapi_FlashProgrammingCommandType oMode)

These are not in HD where all go to one function. Should this be common code between DG and HD?

These are not in HD where all go to one function. Should this be common code between DG and HD?

Do we really want to use a whole flash sector for a flag? I thought bootloader was going to talk to UI to determine whether an update was in progress?

Do we really want to use a whole flash sector for a flag? I thought bootloader was going to talk to UI to determine whether an update was in progress?

What is this for?

What is this for?

This is adding conversion to binary step post-build, correct? Are we losing the alarm check here?

This is adding conversion to binary step post-build, correct? Are we losing the alarm check here?

Don't make changes outside of user code sections.

Don't make changes outside of user code sections.

So app start address is offset by 64K. Assuming that is plenty of room for bootloader but we should check. Also, have we checked that the first 64K of Flash memory is discreet sector-wise? We do no...

So app start address is offset by 64K. Assuming that is plenty of room for bootloader but we should check.
Also, have we checked that the first 64K of Flash memory is discreet sector-wise? We do not want bootloader and app sharing a sector.

Why aren't each of these messages calling their own handler function? They appear to exist in SystemCommMessages.c so I believe that was the intent.

Why aren't each of these messages calling their own handler function? They appear to exist in SystemCommMessages.c so I believe that was the intent.

Should we use new reboot function in Update.c?

Should we use new reboot function in Update.c?

Spaces in (). Be explicit on BOOL conditions.

Spaces in (). Be explicit on BOOL conditions.

Spaces in ().

Spaces in ().

Why not call the reboot function in Update.c?

Why not call the reboot function in Update.c?

Spaces inside (). Be explicit with BOOL conditions.

Spaces inside (). Be explicit with BOOL conditions.

Spaces inside (). Use ternary to set to TRUE or FALSE explicitly.

Spaces inside (). Use ternary to set to TRUE or FALSE explicitly.

Where is this being called?

Where is this being called?

This message will not get sent immediately - it is only queued. Reset will occur before transmit.

This message will not get sent immediately - it is only queued. Reset will occur before transmit.

Where is this called?

Where is this called?

I don't see SystemComm calling this or reboot function. Why are they here?

I don't see SystemComm calling this or reboot function. Why are they here?

These changes look wrong. This is UI comm check.

These changes look wrong. This is UI comm check.

Need doxygen group stuff here.

Need doxygen group stuff here.

Need doxygen group stuff here.

Need doxygen group stuff here.

Why do we need this function? Why not just use the reset function below to start the bootloader?

Why do we need this function? Why not just use the reset function below to start the bootloader?