Not able to access or use BATMON in SAMR21.

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

Hi,

 

I was using bitcloud 1.14 with ATMega128rfa1. In end-devices we were using BATMON for determining remaining battery in the product, and now we switched to BitCloud 3.2 with SAMR21G18A. Porting was success and everything except BATMON is working the way it should.

when I tried use batmon register the compiler was giving error. On searching I found that BATMON was not defined in any file so I tried defining myself.

 

#define BATMON                MMIO_REG(0x42005411, uint8_t)
#define BATMON_OK            5

 

 

//    For BATMON ref
#define BAT_VAL_2V45        0x0F    //    threshold lvl = 2.45V
#define BAT_VAL_2V30        0x0C    //    threshold lvl = 2.30V
#define BAT_VAL_2V20        0x0A    //    threshold lvl = 2.20V
#define BATTERY_THRESHOLD    0x1F    // for making BATMON_HR bit and BATMON_VTHx bits 0

 

Is there some problem with the defination or the address of the BATMON reg? When I tried to print the default value it should be 0x02 but i got 0x00. I thought maybe in PM_APBC mask RFCTRL is off so i have also enabled RFCTRL section.

 

This topic has a solution.
Last Edited: Fri. Oct 16, 2015 - 12:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Where did you get this (0x42005411) location from ?

 

BATMON is an transceiver register, it is not mapped to the MCU memory map. You will need to use BitCloud APIs to work with it. Technically you should not have worked with it before, but it was possible. With R21 it is not possible, since those registers are located on a different physical die.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

Thanks Alexru I was not aware that BitCloud provides APIs for BATMON.

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

There is some API. I've never seen anyone use, so I have no idea if it even works.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

When reading the datasheet for BATMON I found the offset as 0x11 and BATMON is in the section 38 AT86RF233 Module Description, so using product mapping table at page 23 of datasheet I figured the BATMON would in RFCTRL of AHB-APB Bridge C. combining both addresses I got 0x42005411 location for BATMON.

 

Also I found the APIs batmon and tried to use them. But on compilation I'm getting following error: undefined reference to `RF_BatteryMonReq'

 

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

prateekj wrote:
When reading the datasheet for BATMON I found the offset as 0x11

But that is the offset within the AT86RF233 Module's registers. As Alex pointed out, these are not mapped into the Cortex-M0+ memory address space!

 

These registers are accessed over the SPI connection - see 3.2 SAM R21 Interconnection in the datasheet.

 

See also Figure 35-1. Microcontroller to AT86RF233 Interface.

 

To read these "registers", you need to follow the protocol in 35.3 SPI Protocol - specifically, 35.3.1 Register Access Mode

 

 

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

Thanks for the Information. I studied the SERCOM4 for SPI and now using following functions from BitCloud.

 

#include <halRfSpi.h>

void batmonInit()
{
    batmonReg = RF_2V45_BAT_VTG;
    writeBatmonReg(batmonReg);
    batmonReg = readBatmonReg();
...
}
static void writeBatmonReg(uint8_t data)
{
    HAL_WriteByteRfSpi(0xD1);        // MSB 0b11 for write, 0b010001
    HAL_WriteByteRfSpi(data);
}
static uint8_t readBatmonReg()
{
    uint8_t val;
    HAL_WriteByteRfSpi(0x91);        // MSB 0b10 for read, 0b010001
    val = HAL_WriteByteRfSpi(0x00);
#ifdef DEBUG_MODE
    DBG_Print("SpiReadVal:%d",val);
#endif
    return val;
}

On printing the value read from SPI I'm always getting 0.

I tried reading All the register values for SERCOM4 for SPI and the values seems fine. Hope you can give some advice if something else might be wrong.

 

 

I also tried using BitCloud API for BATMON and following is the code:

void batmonInit()
{
    batmonReq.voltage = RF_2V45_BAT_VTG;
    batmonReq.RF_BatteryMonInd = RF_BatteryMonInd;
    batmonReq.RF_BatteryMonConf = RF_BatteryMonConf;
    RF_BatteryMonReq(&batmonReq);
...
}

 

Here I'm getting undefined reference for RF_BatteryMonReq().

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

prateekj wrote:

static void writeBatmonReg(uint8_t data)
{
    HAL_WriteByteRfSpi(0xD1);        // MSB 0b11 for write, 0b010001
    HAL_WriteByteRfSpi(data);
}

So what happens to the slave-select in that...?

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

awneil wrote:

 

prateekj wrote:

 

static void writeBatmonReg(uint8_t data)
{
    HAL_WriteByteRfSpi(0xD1);        // MSB 0b11 for write, 0b010001
    HAL_WriteByteRfSpi(data);
}

 

So what happens to the slave-select in that...?

 

If you are asking about the SS Pin the HAL_InitRfSpi() function is making it output using GPIO_RF_CS_make_out();. We are not calling HAL_InitRfSpi() as we are asuming BitCloud is already calling it to initiallize for RF Communication and we are using the above function after The Device joined the network.

However in the SERCOM4 CTRLB register the bits MSSEN and SSDE are 0, even after devices are in network.

 

Also I'm not using below functions explicitly, can that be the issue.

void HAL_DeselectRfSpi(void)
void HAL_SelectRfSpi(void)

 

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

The SAM R21 datasheet shows you what needs to happen on the SS "pin" during register accesses...

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: 1

DO NOT use SPI directly, you are 100% guaranteed to mess up RF communication. You don't know what stack is doing with the radio at the moment. For example, when RX interrupt happens, ISR initiates transfer and leaves the rest of the work to the main application, since it takes a while and there is no reason to sit there with blocked interrupts.

 

BitCloud APIs make sure that they deffer your request until radio is actually free to execute stuff and is not busy doing something else.
 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

alexru wrote:

DO NOT use SPI directly, you are 100% guaranteed to mess up RF communication. You don't know what stack is doing with the radio at the moment. For example, when RX interrupt happens, ISR initiates transfer and leaves the rest of the work to the main application, since it takes a while and there is no reason to sit there with blocked interrupts.

 

BitCloud APIs make sure that they deffer your request until radio is actually free to execute stuff and is not busy doing something else.
 

 

I tried using the BitCloud APIs too, but on compilation I'm getting the error that the RF_BatteryMonReq() is undefined. Any suggestions why this is happening and how to solve this?

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

The API is PHY_BatMonReq(PHY_BatMonReq_t *req);

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

alexru wrote:

The API is PHY_BatMonReq(PHY_BatMonReq_t *req);

Thanks for the response. I tried using the API you said but still same error

Error    1    undefined reference to `PHY_BatMonReq'    D:\THL_SamR21\Applications\Sensor\makefiles\ATSAMR21G18A/../../src/BatteryMngr.c    140    1    ATSAMR21G18A.

 

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

Yeah, battery monitor support is disabled in the build.

 

If you don't need interrupts from the battery monitor, then you can use simple TRX register access API to setup the monitor and read ok/fail status.

 

Here is example of writing a register

static void appSetXtalTrimValue(void)
{
  static MACHWD_RegAccessReq_t machwdRegAccessReq;

  machwdRegAccessReq.addr = XOSC_CTRL_REG;
  machwdRegAccessReq.value = 0xf0/*XTAL_MODE*/ | 0x08 /*XTAL_TRIM*/;
  machwdRegAccessReq.RF_RegAccessConf = appMachwdRegAccessConf;
  MACHWD_RegWriteReq(&machwdRegAccessReq);
}

static void appMachwdRegAccessConf(RF_RegAccessConf_t *conf)
{
  (void)conf;
}

 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.