CC26xx Driverlib NONBUF_BASE definitions

I still wonder what these addresses are. I guess this is some kind of hack to work around Cortex-M3 bus store buffer. But it's not clear why driverlib code uses this hack. There is no any information in errata. And also no description of driverlib code. CC2650 manual also keep silence.

Hey, TI guys, please, explain what NONBUF_BASE definitions mean?

Hello Andrey,

I will check with our driverlib team. Are you encountering an issue?

Best wishes

Hello, JXS

Yes, our device sometimes falls into the weird state: unexpected data in packets, bad-formed packets, frequent connection drops, etc. This weird state is rarely appeared bug, but it exists.

We use our own stack and HW layer, so this is not driverlib problem. But I want clearly understand what and how driverlib does because I use it's code as a reference when analyzing our own code.

Now I waiting for driverlib team response. Thank you.

BR,

Andrey

Hi Andrey,

The NONBUF_BASE is a mapping to the same area, but avoids using buffered writes. That is to say, the PC will not increment until the memory bus has acked the write. I have to admit I don't know the specifics on how this works. Normally, writes are done to buffered memory, which is more efficient, but may in some cases not be desirable.

If you set the register ACTRLR:DISDEFWBUF to 1, all writes would be non-buffered. This is useful for finding the at-fault location for bus errors, like writes to non-existent memory.

In the case of peripherals, it can be useful to use non-buffered writes if you get an exception with CFSR:IMPRECISER set and suspect that maybe the peripheral isn't enabled. Non-buffered writes would (usually) convert the IMPRESICER to a PRECISER with BFAR set to the address attempted to be read or written.

Best regards,
Aslak

Hi Aslak,

Thank you for your explaining.
So, we have to use nonbuf writes exactly as driverlib does to avoid possible bugs? Or these writes are some kind of debugging technique, which accidentally was not removed from driverlib code?

BR,
Andrey

Hi Andrey,

This has probably been done on purpose if these are used in drivelib code. Can you provide an example of a driverlib API call where you see NONBUF and where you are surprised to see it? I can then either attempt an explanation or ask for one from the gurus.

In general I will observe that for peripheral modules where the memory mapping actually goes into state machines/hardware registers it could be necessary to use non-buffered writes so that the sequence of operations is guaranteed and synchronized between M3 core and the peripheral hardware.

We have no known bugs to my knowledge relating to the TI-RTOS drivers' usage of the current driverlib APIs, so doing it the same way as driverlib would be my recommendation. We do also recommend using driverlib instead of writing to hardware registers manually.

Best regards,
Aslak

Hi Aslak,

Here is list of all occurences (received by 'grep -nr NONBUF_BASE' in driverlib directory):
./driverlib/rfc.h:126: HWREG(RFC_PWR_NONBUF_BASE + RFC_PWR_O_PWMCLKEN) =
./driverlib/rfc.h:161: HWREG(RFC_PWR_NONBUF_BASE + RFC_PWR_O_PWMCLKEN) = 0x0;
./driverlib/rfc.c:145: HWREG(RFC_PWR_NONBUF_BASE + RFC_PWR_O_PWMCLKEN) = (HWREG(RFC_PWR_NONBUF_BASE + RFC_PWR_O_PWMCLKEN) & ~RFC_PWR_PWMCLKEN_CPE_M) | RFC_PWR_PWMCLKEN_FSCA_M;
./driverlib/prcm.h:559: HWREG(PRCM_NONBUF_BASE + PRCM_O_CLKLOADCTL) = PRCM_CLKLOADCTL_LOAD;
./driverlib/sys_ctrl.c:195: HWREG(RFC_PWR_NONBUF_BASE + RFC_PWR_O_PWMCLKEN) = 0x7FF;
Almost all of these related to RF clock setup.

I've already start migrating our project to driverlib code. It seems this is the only way to be sure bug is not HW layer related.

BR,
Andrey

Ok, Aslak, I've got it.
Thank you so much)

BR,
Andrey