DFU time limit of 60 seconds can't be extended past 65 seconds?

[Gil dePaula]

Hi all,

This 60-second limit is not enough for us. Our application is 48 kB & takes 35 seconds to upload. It should be enough, but the problem is that our iOs app does DFU like this:

1. Sends a command to the main application to jump to Bootloader.
2. The application does so (sets bit in the gpregret), and the Bootloader statrts.
3. Problem: Now we cannot start the upload yet because we have to "forget this device (the application device)" in iOS, connect to the "DfuTarg" device (which takes a few seconds to be visible) and finally start the upload, but this process takes a little more than ~35 seconds. .... So the total time is about 70 seconds!

I tried to increase the time here (#define DFU_TIMEOUT_INTERVAL APP_TIMER_TICKS(120000, APP_TIMER_PRESCALER) to 2 minutes (12 s) but the maximum it goes is about 65 seconds. (65535 ?) Bug? Register is 16-bit instead of 32-bit?

How do I increase it to 2 or more minutes, for example?

Thanks! Gil

Edit: format

[John]

I'm not sure why your timer isn't going out to two minutes. I've set timers as long as 5 minutes without a problem. That said, why don't you just restart the timer every time you get a packet? Then your timeout will not occur until there is 1 minute of inactivity.

[Gil dePaula]

Yes, I've set those app timers for longer than that as well. But for this one, I load a longer count, and it always times outat 65 s. I'll try to reload (stop/start) for each packet like you're suggesting. That's a good idea and it should work. Thanks!

[Gil dePaula]

I checked and the Bootloader example already does that. I suspect it's a timer bug in the SoftDevice that only takes the counter value ( > 16 bits) but only counts to 16 bits, instead of 32 bits, and it's not re-loadable. I'll wait and see if Nordic gives me any feedback. Thanks John!

[Wojtek]

Do you have some new information? I need my bootloader to have shorter timeout time (10sec would be nice), but with ability to restart timer after each received packet, but it doesn't seem to work properly right now.

[Tim Clark]

Curious if anyone ever got this figured out -- I think we're getting bitten by the same issue!