I understand the issue is confusing and even we are baffled. We do not know at this point for certain whether it is a hardware issue or a software one, or a combination.
Wayne: Do you mean this issue only happens to your customized image? It does not matter about the carrier board?
Yes, the issue happens only with our customized image, and when our carrier board is used to flash the Nano. Suppose the Nano is flashed like this and does not boot on our carrier boards, and if we use the same Nano which was not booting on our carrier board on Auvidea’s carrier board, it boots, but we do not intend to use Auvidea carrier boards in field at least as of now.
When I say ‘clean’ image, I mean to say I remove the system.img and system.img.raw files, and run the flash scripts so it generates the ‘new/clean’ image. But each time, it is with our customized kernel and device tree.
Wayne: It seems issue is related to carrier board again. Which one is true here?
As discussed above, we do not know for certain if it is the carrier board issue. It could be that something goes wrong with the electronics while flashing, rendering the Nanos non-bootable (and also I was wondering if you could help with indicating if I could debug something into the BSP). The main problem is that if I encounter such a situation when a Nano does not boot on our carrier boards (after flashing on our carrier boards) it is not recoverable, which means no matter how many times I flash it and with a ‘clean’ image as discussed above, or even re-compiling the entire kernel+device tree before, the Nano does not boot on our carrier boards but does so on Auvidea’s.
This is the “relation” I was refering to in #12 - somehow only some Nanos are not suitable for our carrier boards (we always use the same image), and cannot be made so.
There are multiple such units till now. So what we observe is if we flash a unit on our carrier boards which somehow makes it non-bootable on our carrier board, then the Nano is non-reclaimable as I explained, and also we have to allow the flash script to generate a new system.img* (by not passing the ‘-r’ option) and deleting the old system.img*, when we move on to flashing the fresh Nano unit. Otherwise we create another non-reclaimable unit.
So, our focus at the moment is to somehow reclaim those units, and prevent such an occurrence in the future. What we now do is create a new system.img* each time for flashing a Nano, and deleting the old image once it is done. This process is slow, but somehow safe till now. We have to flash a large number of Nanos and possibly in an automated way in the future (but right now this isn’t the problem I intend to put forth). Basically, we somehow have to prevent producing a non-bootable Nano because there are high chances that if we hit one such unit, we create other non-reclaimable units.
Let me know if this information helps further.