need help -> processor does'nt allow writing to USARTF0

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am trying to configure four USARTs on ATxMega256A3.
USARTC0, USARTD0, USARTD1 and USARTF0.

I am able to write to the CTRLA, CTRLB, BAUDCTRLA and BAUDCTRLB registers for all except USARTF0.

I even debugged in disaasembly and I can see the instructions right there to write to USARTF0 address

REG(MODBUS3_CTRLA) = 0x20;
00001457 LDI R25,0x20 Load immediate
00001458 STS 0x0BA3,R25 Store direct to data space

REG(MODBUS3_CTRLB) = 0x10;
0000145A LDI R24,0x10 Load immediate
0000145B STS 0x0BA4,R24 Store direct to data space

REG(MODBUS3_BAUDCTRLA) = baudCtrlA;
0000145D LDD R18,Y+1 Load indirect with displacement
0000145E STS 0x0BA6,R18 Store direct to data space

REG(MODBUS3_BAUDCTRLB) = baudCtrlB;
00001460 LDD R18,Y+2 Load indirect with displacement
00001461 STS 0x0BA7,R18 Store direct to data space

The values just doesn't get updated in the registers.

But, if I try to manually write to the registers using the debugger, it holds that value.

Attached is a debugger screenshot.

Any ideas why this could be happening?

Thanks,
Sam

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you check if the PR bit for USARTF0 is on? If PR bit is disabled, then you won't be able to write to the registers associated with that interface in the application code.

The debugger might have some kind of overwrite priority where it is not constrained the same way in-application instructions are executed.

If you use the debugger to overwrite the values and then let the program run, does the USARTF0 work then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems odd that you write everything twice. Could you be writing three times?

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi mspeng, thanks for your advice. That could surely be a problem.

Hi Jeff,
I was trying to make sure that data is written using two different approaches.

Anyways, the real problem was found in atmel studio.

At some point during debugging, apparently my windows
7 got updated and something caused my debugger to get disconnected from the atmel studio. As a result, what I was looking at was the simulator and not the real processor.