• AVR Freaks

AnsweredHot!Unexpected MCLR reset during debugging

Author
manuelsibo
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2017/12/12 08:36:49
  • Location: 0
  • Status: offline
2018/02/08 02:26:38 (permalink)
0

Unexpected MCLR reset during debugging

Hi everyone!
This is my first post on this forum so if I make some kind of mistake please understand me...
My configuration is:
- PIC24FJ256GB606
- MPLABX v4.05
- XC16 v1.33
- PICKIT3
This is my problem:
when I debug my project I have an unexpected MCLR reset. I noticed that reading the RCON register (0x2083) where the bits SBOREN, EXTR, BOR and POR are set.
If I read the value of PC it points always to the same address (0x2F6) where the assembly instruction is "RESET".
Putting a breakpoint It appears that the code where this happens is referred to a SPI function that writes to my SD card. This seems strange to me because this function never gave me some kind of error...
Somebody can explain this? Thank you.
#1
NKurzman
A Guy on the Net
  • Total Posts : 18191
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Unexpected MCLR reset during debugging 2018/02/08 10:13:21 (permalink) ☼ Best Answerby manuelsibo 2018/02/09 02:40:03
0
Do you have the Traps coded?  it could be an exception.
#2
manuelsibo
New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2017/12/12 08:36:49
  • Location: 0
  • Status: offline
Re: Unexpected MCLR reset during debugging 2018/02/09 02:44:07 (permalink)
0
Sorry for my ignorance but...what do you mean with "traps coded"?
If I have understood you mean to turn a led on os so on...is it correct?
thank you
#3
Ekkehard
Starting Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2018/01/01 16:25:16
  • Location: 0
  • Status: offline
Re: Unexpected MCLR reset during debugging 2019/12/19 01:32:19 (permalink)
0
Even the OT is nearly two years old, I would like to comment this, since I digged around with a close problem.
I wrote a function which takes a pointer to a double word (*uint32_t) as a parameter and does some calculation with the content.
The function was feed with the address of the first element of a byte array. I called the function first with a local array and with second with a global array. The second call commited a reset, when the pointer target is copied to a local variable.
The RCON register (unfortunately not every time) comes up with 0x8083, which leads direct to the "Trap". Since my application make no usage of any interrupt, the "Trap" is not able to recover and leads to the reset. Once this was identified the Datasheet (in my case PIC24FJ64GA104 FAMILY ) says in chapter 4.2.2.
All word accesses must be aligned to an even address.Misaligned word data fetches are not supported, so
care must be taken when mixing byte and wordoperations or translating from 8-bit MCU code.
If amisaligned read or write is attempted, an address errortrap will be generated.
In my case the array was defined as
uint8_t GlobalBuffer[8];
and the function
uint32_t TrapTest(uint32_t * ATestValue) {
uint32_t v = *ATestValue;   
return v;
}
Stupid enough the GlobalBuffer[0] was located on an odd address in the RAM, so the assignment to the local variable v caused the trap and the subsequently reset. In the previous call using a local buffer the address of the first byte was located on an even address and everything runs smooth.
Since not always the trap flag in the RCON showed up, it tooks me a while to understand the problem...
There are two solutions possible.
1.) ensure that all used arrays are located on even addresses. This could be realized with the align attribute. The modification as follow does the job for me:
uint8_t __attribute__((aligned(2))) GlobalBuffer[8]; 
2.) if the data structure in the array may cause the situation that words may lay on odd addresses than you have to deal with it in the function using byte copy functions instead of assignments (and pay for/with less performance).
memcpy(&v,*ATestValue,sizeof(v)); // instead of v = *ATestValue
I wrote this here in length, since I did not find an explanation under the key words "PIC24" "unexpected" "reset", in the hope that it might useful.
 
Greetings Ekkehard
#4
Jump to:
© 2020 APG vNext Commercial Version 4.5