Defined Value Changing

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

Hello,

 

I've been working to try and get some readable data from an IMU for awhile now (MPU-6050) but I've run into a really strange problem where it seems a defined value is changing.

 

This is causing all the code to not work because the value that's changing is the TWIE address on my XMEGA. (line 8 #define MPU_TWI &TWIE in mpu.h).

 

When I pause the program that's running, the port* value will be reported as 0x02a0 or 0x00a0 instead of the 0x04a0 that it should be. 

 

I get the feeling it's probably the TWI code (See lines 42-46 of twi.c) doing some funky things so I'm going to use the atmel provided TWI example code and rewrite the MPU code to work with it instead, but I figured it might be worth it to post what I have here and see if someone might be able identify a silly mistake before I go about doing that.

 

Thank you!

Attachment(s): 

This topic has a solution.
Last Edited: Tue. Dec 3, 2019 - 09:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are NOT defining a "constant" or a "value". Remember, macros only result in text substitution. So, if TWIE changes, so will MPU_TWI. What happens will depend totally on how the macro expression is used.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Why would the address of TWIE change when it's a hardware constant? It's the address of the TWI on Port E as defined by device type (128A1U).

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

Just looked at the XMega E manual and could not find TWIE anywhere. On regular Mega chips, that is a BIT name and number.

 

Ooops, XMega128AU has a TWIE register. Sorry. Nothing further, here.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Thu. Nov 21, 2019 - 06:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
void XBeeSendStrInt(int16_t number)
{
	int16_t length = snprintf( NULL, 0, "%" PRId16, number );
	char temp[length];
	char* str = temp;
	snprintf( str, length + 1, "%" PRId16, number );

Writing length + 1 to an array of size length, so it's going to be overwriting something when it writes the null byte at the end of the string.

Make the array 1 longer.

Whether that is causing your specific problem I don't know, but I would fix it first. Likewise in the SendDbl function.

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

Definitely unrelated but thanks for the catch!

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

Astray wrote:
... and see if someone might be able identify a silly mistake before I go about doing that.
A linter somewhat finds my silly mistakes or produces a hint to follow through on.

 

"Dare to be naïve." - Buckminster Fuller

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

Astray wrote:
Definitely unrelated

How so sure?

 

Bizarre behaviour and values "magically" changing of their own accord are classic symptoms of a  buffer overrun!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because the function it's from isn't called at all in that current version of the code before it breaks.

Last Edited: Fri. Nov 22, 2019 - 01:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Astray wrote:
the value that's changing is the TWIE address on my XMEGA

As already noted here and in your subsequent thread, that's clearly nonsense!

 

Astray wrote:
the port* value will be reported as 0x02a0 or 0x00a0 instead of the 0x04a0 that it should be.

 

0x04a0 is the address of the port:

#define TWIE                  (*(TWI_t *) 0x04A0) /* Two-Wire Interface */

 

But port* is  not an address:- the '*' here is the pointer de-reference operator - it gives you the data found at that address.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am happy to report that I have gotten the code working with defines by using volatile when passing the port.

 

I don't want to post 200+ lines of code here so I'll just include them in a file below. This will get raw and scaled data off an MPU6050 using TWI for xmega.

 

 

Attachment(s): 

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

Astray wrote:
I am happy to report that I have gotten the code working

Jolly good.

 

Now please mark the solution - see Tip #5.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...