Hi Jace, can you share more details on the CPU19 bug? (per PN or under NDA if required) If the CPU19 bug is hard to reproduce that would match my observations: insert some instructions at a non-related place in the code makes it disappear. But that could also be true for a totally different bug (sw or hw). I want to make sure that this is the CPU19 bug, insert the nops and be sure that I fixed the right issue. Inserting pin toggles at different places is hard, because depending on 'something' (what? depends what the cpu19 bug depends on...) the bug does not appear. I dumped SFRs and peripherals from 0x0-0x1ff on different runs and compared them with each other but I can't see anything suspicious. There are a few non-assigned locations which read garbage but for the defined peripherals the values are the same/correct or different due to their nature (TAR/TBR, ADC, ...). From a user perspective I'd say the range from 0x0 to 0x1ff + the cpu registers define the visible MSP430 state. The application spends quite some time entering/leaving exactly this state with some minor differences in RAM, but it always fails at the 36th loop, if it fails. More information about the dependencies of the CPU19 bug would be very helpful, also with regard to the F148 based board. Best regards, Lo
↧