CC2640R2F: How to migrate micro_eddystone_beacon code to support CC2640R2 2.7x2.7 DSBGA package?

Thanks.

I'm still stuck with migrating from 7x7 to the small 2.7x2.7 package.

Trying to run the 7x7 code on the small 2.7x2.7 package, it hangs on ti_sysbios_family_arm_m3_Hwi_excHandler__I() , CFSR=0x00000400 (IMPRECISERR=1)

Which #define(s) should I change?

Should I avoid using some peripherals/GPIOs?

I did two debug sessions:

1. Please see below:

the assembly lines around the offending opcode are:

2. The Board_shutDownExtFlash() function is called in order to save power. It was necessary to achieve low power on CC2640R2_LAUNCHXL. The custom board with 2.7x2.7 DSBGA package doesn't have external flash, so I commented out the call to Board_shutDownExtFlash(). (BTW, does it also save power by disabling internal related peripherals?) Now, without Board_shutDownExtFlash(), I get the following exception:

the assembly lines around the offending opcode are:

Thanks for looking into it.

My board files did have pins that don't exist in the 2.7x2.7 DSBGA package, because the code is based on example for 7x7 package on the CC2640R2_LAUNCHXL board.

In CC2640R2_LAUNCHXL.h I replaced every IOIO_xx greater that IOID_13 to IOID_UNUSED

Now I don't get CPU exception, but the code doesn't work right, and doesn't transmit the beacon.

Narrowing down the code that doesn't work right, I found that in the following function (found in micro_eddystone_beacon.c) :

line #695 is reached 3 times, and in the 3'rd time, Event_pend() doesn't return. It neither get stuck nor get CPU exception, and when suspending execution, I get various code locations (examples listed below).

When executing the same code on CC2640R2_LAUNCHXL, line #695 is endlessly reached, and the beacon is transmitted OK.

List of examples where the code is, when being suspended:

ti_sysbios_family_arm_m3_Hwi_dispatchC__I()
PowerCC26XX_standbyPolicy()
Break at address "0x1000044a" with no debug information available, or outside of program code.
Break at address "0x10001dea" with no debug information available, or outside of program code.
__aeabi_lmul()
ti_sysbios_knl_Clock_walkQueueDynamic__E()

Some board differences:

Both boards have two external crystals: 32.768KHz and 24MHz.

Thanks for your support.

Update:

After checking a few more boards for this custom board prototype assembly batch, one of them did work OK and transmitted the beacon. This leads me to the conclusion that it is a soldering issue with the fine pitch BGA.

(Any idea which pins might cause such behavior?)