Optimized code stops working

RE: Optimized code stops working

Susheel Nuguru — Mon, 08 Jun 2015 12:54:32 GMT

please update your post Jose.

RE: Optimized code stops working

Susheel Nuguru — Thu, 16 Apr 2015 14:21:56 GMT

Agree, it does not look like the optimization problem is from this code.

RE: Optimized code stops working

RK — Thu, 16 Apr 2015 12:26:47 GMT

I can't see anything with that code which would be affected under optimisation, at all. Which makes me wonder if that's really where the problem is or if it's elsewhere entirely and what we're seeing is the aftermath of a debugging session's worth of edits.

I agree all the registers are volatile, all the loops should remain, all the values should be read and not optimized out. Without seeing the assembler it's hard to know what's going on.

The only 'clue' was in the second message from the OP who said packet has data but buffer doesn't, so I thought CRCSTATUS

sending received[1] to app_uart_put is fine, a byte is expected so the compiler should mask off the top and send it in r0 or assume the routine will mask it somewhere itself. It's a one-argument function so it would get passed in the full 32bit r0 either way

I agree odd to use uint32_t[] but not incorrect that I can tell.

RE: Optimized code stops working

Susheel Nuguru — Thu, 16 Apr 2015 12:10:59 GMT

given the code he showed here, there is nothing else optimizable apart from those. So if it works with no optimizations it has to be either variables or arguments. Rest of all the code are volatile device registers. Agree that it is legitimate to copy uint8_t into uint32_t. What happens if you put uint32_t in uint8_t in app_uart_put(received[1]), i am guessing this should be ok too as only LSB is copied and the rest ignored?

RE: Optimized code stops working

RK — Thu, 16 Apr 2015 11:19:57 GMT

No there's nothing wrong with that code. It's odd, admittedly, taking the uint8_t and putting them into a uint32_t array, but it's quite legitimate code. I assumed that was why he has the 6 individual array assignments instead of a memcpy().

the buffer pointer 'packet' itself is a uint8_t and that's the one handed off to the RADIO module so it's fine. That's the one which needs to be a byte pointer.

RE: Optimized code stops working

Susheel Nuguru — Thu, 16 Apr 2015 10:47:47 GMT

uint32_t received[6]

change this to

uint8_t received[6];

and

bool read_packet(uint32_t *buffer)

change to

bool read_packet(uint8_t *buffer)

RE: Optimized code stops working

Susheel Nuguru — Thu, 16 Apr 2015 10:38:30 GMT

sorry editing my previous reply as I posted that without seeing into the rest of code, ill answer this soon

RE: Optimized code stops working

RK — Thu, 16 Apr 2015 07:58:26 GMT

ok you have to reset the packetptr every time before you call start, but if you're only doing 1, not a problem. For code readability perhaps setting it right before the TASKS_START is good.

Your second comment 'before the optimisation flag I could see the data on the packet pointer but not on the buffer'. Do you mean before you turned OFF optimisation? If you can see data in the packet pointer but not the buffer that would seem to indicate CRCSTATUS is zero so it didn't get copied into your buffer.

I still don't know what this has to do with optimization - trying to rule out the obvious things first, then I suspect it's time to get into the assembler.

RE: Optimized code stops working

Jose Xavier — Thu, 16 Apr 2015 07:39:06 GMT

static uint8_t packet[6];

and I set the pointer after radio_configure();

radio_configure();
NRF_RADIO->PACKETPTR = (uint32_t)packet;

I'll set a bool to know if the CRCSTATUS is 1 or not.

Only after change the optimization flag I got the same exact code working on the same exact condictions. Before the optimization flag I could see the data on the packet pointer but not on the buffer.

RE: Optimized code stops working

RK — Thu, 16 Apr 2015 02:26:15 GMT

What's result and what's packet? You define result but don't use it, you use packet but it's not defined in the code you posted. If you're using easyDMA where's the pointer reset before you send the START task?

Do you know if CRCSTATUS is 1 or not? If it's not then buffer isn't re-filled and has whatever garbage was in it when you called the function. Perhaps a failure return from the read function would help in that case.

None of that has anything to do with optimization, but it's hard to figure out what could even be happening without a bit of clarification.

Have you looked at the compiled assembler to see what it's doing? You would hope the compiler is smart enough not to compile out the while loops as the fields are marked volatile but it's worth checking.