Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

ovrebekk — Wed, 16 Nov 2016 08:44:31 GMT

No worries, thanks :)

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Wed, 16 Nov 2016 02:09:11 GMT

Got that. Sorry for forgetting it.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

ovrebekk — Tue, 15 Nov 2016 14:16:57 GMT

Please accept the answer if you think the issue is resolved.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Thu, 20 Oct 2016 05:50:42 GMT

You are right. With the current badly optimized version of our firmware, we are already at 20kB code size, that is without Dual Bank, Persistent Storage, Device Manager or Peer Manager, all of which we do hope to add. Decreasing the code size has been a struggle. So any tips would be much appreciated.

Also thanks for your idea with DFU retry. I didn't think about it. I will let our smartphone app engineers know.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

ovrebekk — Tue, 18 Oct 2016 07:50:36 GMT

It depends on how you handle it in the application. If you automatically retry it will only increase the DFU time. Also, unless you actively try to interrupt the DFU process, or the battery is almost depleted, it shouldn't fail.

Dual bank DFU is better than single bank for sure, but when trying to squeeze a SoftDevice, bootloader and 2 times the application into 128kB you might have to sacrifice a lot of functionality to get there.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Tue, 18 Oct 2016 02:27:26 GMT

I think it is fairly important. Mostly for user experience. We imagine the more non-tech consumers would be confused if a failed update semi-brick their device.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

ovrebekk — Mon, 17 Oct 2016 08:54:45 GMT

Keil defines the following data types: RO (read only), RW (read write) and ZI (zero initialized) The only difference between RW and ZI is that RW data is initialized to something different than zero.

RO variables only take up flash space RW variables take up both RAM and flash (the flash is used to store the init values) ZI variables only take up RAM, and are initialized to 0 automatically at startup.

How critical is it to use dual bank DFU? The only difference between single and dual bank is that if something fails when doing single bank update you have to retry the DFU operation until it succeeds.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Fri, 14 Oct 2016 08:50:18 GMT

I just read this question and I think I grasp things a little better now.

So overall trying to avoid global/static variable is not going to benefit me in anyway because both Code, RO and RW Data takes Flash space...

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Fri, 14 Oct 2016 08:34:10 GMT

The second is the code size limit by MDK-Lite. For this I believe I only need to make sure (Code + RO Data) to be less than 32kB, and I believe that global and static local variables increase RO Data size.

I think I understand what you meant by converting multiple global/static variables into one managed by a state machine. That should be just converting size taken by RW Data into taken by Code, and thus actually badly impact me for MDK-Lite limitation. I didn't think that through.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

Hieu — Fri, 14 Oct 2016 08:33:47 GMT

Hi Torbjørn,

I must first admit that I am not well versed on how memory is allocated on flash and on RAM while running. So please advise me. From what you said I already feel like some of what I understood is wrong.

There are two size constraints that I need to consider.

First we use an nRF51822 QFAB, with S110, and plan to have Dual Bank DFU and some persistent storage, so I think I need to use less than 12kB of flash to be safe. Regarding this, I have little knowledge and am now starting to research how my code impact Flash and RAM consumption. So any tips or keywords to push me in the right direction is really appreciated.

RE: Avoiding HardFault and Optimizing Code Size with TWI Transaction Manager

ovrebekk — Fri, 14 Oct 2016 07:20:07 GMT

Your guess is correct. If you want to declare the transfer or transaction structs inside a function other than main() you have to make them static, otherwise the data will be overwritten by the time the TWI driver uses them. The TWI driver runs various asserts on the data to ensure it is valid, and this is likely to fail if the data has been overwritten.

Is it code size, RAM size or both that you need to optimize for? Having all your structures global or static will only affect your RAM consumption, not your code consumption. Even if you only define one structure at a time you still need to have that data in the code somewhere.

If you do want to pass one transaction at a time to the TWI library you probably need some kind of state machine in the application, where you wait for TWI events and feed one transaction at a time into the library. That being said I think this will have a larger impact on code usage than simply having all the transactions global/static, so I wouldn't recommend it.