Hi,
we are ramping up production, and need to make many production jigs, and programming in parrallell since the programming of the modem takes 1 min +.
We are using an stm32 on each jig, and programming the 4 processrs successfully (9160, 822, 840 and 833) however, when trying to update the modem firmware in the 9160 it fails.
(we do all this in parralell, so we are 4 times faster than using seggers, and the cost (factory wants 8 jigs) is a lot less, and faster and more reliable since programming the modem with the segger fails about 50% of the time and needs to be restarted (using nrfjprog etc).
We have tried to follow both recommended and alternative method from https://infocenter.nordicsemi.com/index.jsp?topic=%2Fnan_041%2FAPP%2Fnan_production_programming%2Fintro.html
and looked at the latest nrf_dfu_api.py but to no avail.
Basically the instructions are flawed in many areas, but we get to the point where we can successfully verify the digest of the modem so that we know what fw loader we need to program in ram, we get acknowledment that the fw loader has started, and we get no errors during the programming when we use the recommended routine, but when we try to verify the firmware digest we get errors.
The nrf_dfu_api.py uses a third method that is completely different than what the description is, and for now we ignore this. (it programs in chunks of 261096 bytes and pads both end and beginning with 0xFF to accomplish 8kB boundaries when programming.
The alternative method description does..
So the questions we have:
Is there an updated firmware update procedure we can take part of?
if not, can you elaborate:
-
Split the contents of the HEX file into contiguous sections that are page aligned and 7 KB large.
What do you mean by page alinged? What page size? 7 kB is never aligned to 4 kB page size.
Should we repeat step 3 to 9 rather than step 4 to 9?
when all is fihished, shall we do anything more before we verify? - Verification:
We can't even verify a correctly written fw (with nrfjprog).
in the digest file, we have 4 sha digests (we get neither, because if we do what the .py file does, we get different errors depending if we first load the fw loader in or not.
without the fw loader loaded (but everything preppared, ie up until we've read out the diget of the fw loader correctly) we get theNRF91_IPC_FAULT_EVENT set to one.if we load the firmware in the processor before we try to do the verifcation we getNRF91_IPC_COMMAND_EVENT set to one, but when we read out0x2000000C we get error 0x5a000002, and when then reading 0x20000010 we get error 3. (this is taken from the procedure of modem verification in the py file.. it is not mentioned in the description.)The area 0x20000010 to 0x20000030 is always 3000060000000005000000c027000006c2ea1fd no matter if we read out on 1.3.5 or 1.1.6 (the modem fw in the chips originally).
. There is something cryptic about this written in the procedure (-
0x2000000C writes (0x3) and reads (0x7) responses from the modem. If the response is 0xA5xxxxxx, it is an acknowledgement of the command. If the response is 0x5Axxxxxx, it is an error where the last six digits is the error code.) but there are no descriptions of error codes.
As you can read we're getting to worlds end with this, can you please elaborate how the recommended method is going to work, and why the python scrips you provide don't use that method?
-
