DA9063 versions and register maps

15 posts / 0 new
Last post
pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
DA9063 versions and register maps

Hi,

I'm an Embedded Systems Engineer developing BSP for one of my company self-designed board where we use a Dialog DA9063-3FHK1 PMIC.

While implementing Linux support for PMIC regulators monitoring, I found out that different versions
of the DA9063 PMIC exist. They don't have the same register map.

As I can't figure out what register map my PMIC version belongs to, I'm posting here in order to know
how to find out the exact register map that is implemented in the DA9063-3FHK1 version.

Best regards,

PinkPR

Device: 
ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hello

The best way to check the register values is to use the DA9063 GUI, this will allow you to check each register and its function. The -3FHK1 code describes the package, the 3F is the Variant number (OTP) and the HK1 is the physical package details.  

The 3F Variant is in the process of being replaced by the 82 Variant, this Variant however is still going through the process of being released. I would recommend using the 82 variant in the future.   

Kind Regards,

Elliott Dexter

 

Click here for the Link to the DA9063 GUI. 

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
Hi Elliott, thanks for

Hi Elliott, thanks for answering.

From what I understand, the DA9063 GUI is made to be used with the DA9063 Eval board.
I don't have this eval board, plus I can't find the DA9063 GUI on the internet.

I'm actually not trying to find what's inside the OTP, but I'd just like to check if the register addresses on my PMIC version are compliant with what's written in the Linux source files.
I'd especially like to check for the ADC part. There is no ADC feature implementated for DA9063 in the Linux Kernel, and that's what I'm working on.

PinkPR

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hello PinkPR,

DA9063 GUI

The GUI itself can be used without a Performance or Eval board, this will allow a user to check and edit OTP register settings but will not allow the user to check the OTP with the PMIC. 

Click here for the DA9063 Support Page.  The GUI is called PowerCommander 

 

Chip ID and Variant 

There are two register maps in the DA9063 driver. The AD tables and the BB tables, the BB tables are used for the DA9063 driver.

The chip ID and variant register values are used to detect the chip type. These registers are:

#define                DA9063_REG_CHIP_ID                  0x181

#define                DA9063_REG_CHIP_VARIANT                    0x182

 

ADC Mapping 

Under

https://support.dialog-semiconductor.com/pmic-audio/device/da9063?qt-pmic_device=1#qt-pmic_device

Documents > Freescale BSP >

There are DA9063 Android integrations. These contain examples for the HWMON driver for the DA9063 as integrated into the Freescale/NXP Android releases.

 

The latest release, DA9063 i.MX 6 Lollipop Android L5.1.1 2.1.0 BSP has a  ZIP file, which is the DA9063 i.MX 6 Lollipop Android L5.1.1 2.1.0 BSP.zip,  this contains a hwmon example for DA9063.

 

Kind Regards,
Elliott Dexter 

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
Hi Elliott,

Hi Elliott,

Do you know why internal regulators monitoring is not implemented in the hwmon driver ? That's precisely the feature I'm looking for.
I'll try to add this feature on top of the base driver you provided.

PinkPR

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hi Pierre-Olivier,

 

In the past, over/under voltage interrupt handlers were too specific to be included in the general Linux driver and the kernel maintainers would not support their addition. The example in the Android implementation shows how the Android version needs to implemented for monitoring on the Dialog PEBIX reference platform, but it is believed any implementation will contain platform specific components.

 

Kind Regards,
Elliott Dexter 

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
Hi Elliott,

Hi Elliott,

Thanks for your answer. I still can't find how to perform ADC manual conversions on internal regulators.

I literally followed the "Monitoring Output Voltages --> Manual Measurement of Regulator Output Voltages" part (part 6.4, page 13) of the AN-PM-024 DA9063 Voltage Monitoring document, and it doesn't seem to work at all.
Plus I noticed some differences between this document content and the Datasheet content.

For example, the document tells to set MON_A8_IDX = 0 to select BUCKCORE1 monitoring. But according to the datasheet, you should set MON_A8_IDX = 1.

So what's true, and what's not ?

PinkPR

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
And by the way, what are the

And by the way, what are the differences between the 3F and 82 versions ?

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hi Pierre-Olivier,

 

Datasheet and Application note:

The DA9063 datasheet states a register value of 1 for BUCKCORE 1 and AN-PM-024 mostly states a register value of 1 for BUCKCORE1. However there is a typo in one of the tables in AN-PM-024, table 12, it states 0h, and this should also be a 1 to be correct and consistent with the other table. Thank you for pointing this out, we will update the document.

 

Variant 3F and 82:

Variant 3F and Variant 82 are very similar; there are a few minor changes to certain regulators voltages, current limits and start-up slots. There are also a few changes to minor registers but nothing that  significantly changes its operation or purpose. The changes were recommended by customers and customer requirements.

 

ADC

When you said that you followed the document and it didn’t work at all, what did you mean?

 

Kind Regards,
Elliott Dexter 

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
I'm actually trying to get an

I'm actually trying to get an ADC-measured voltage value for each of the regulators.

1. I reset the ADC by writing in the ADC_MAN register the value ADC_MUX (8, 9, or 10 according to what group the measured regulator belongs to).
2. I write the index related to the regulator in MON_REG_5 or MON_REG_6.
3. I write the ADC_MAN bit (1 << 4) in the ADC_MAN register.
4. I wait for the value to be ready by waiting for the E_ADC_RDY bit (1 << 3) to be set in the EVENT_A register.
5. I get ADC_RES_H and ADC_RES_L and merge them in order to rebuild the conversion result.

The problem is, for every regulator that belongs to group A8 or A10, that I get a ADC_RES_H and ADC_RES_L full of high bits (OxFF).
In the case of A9, I get different values depending on the regulator, but they aren't logical at all.

For example, I have (in reality) LDO1 voltage > LDO2 voltage. But my ADC conversion tells the contrary.

Those illogical behaviors make me think that's there is a BIG problem in my algorithm, and it could come from bad infos from Datasheets / Application notes I have.
That's why I'm coming to you and ask for help :-)

PinkPR

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hi Pierre-Olivier,

I followed the instructions from the applications note and didn’t have any of the issues. I will list my steps, starting from variant 3F; I will use LD05 set to 2.8 V as an example:

  1. Set ADC_MUX to the required channel. For LDO 5, ADC_MUX is set with 0x1001.
  2. Set the Mon_A9_IDX to the required index. For LDO5, MON_A9_IDX is set to index 6.
  3. The Manual conversion will now need to be triggered. For the Manual conversion to be ADC_MAN = 1, this register will reset back to 0 when the conversion is finished.
  4. The results of this operation should now be in ADC_RES_H and ADC_RES_L, the results I get from this operation is 2.8 V  

 

Register Breakdown:

  1. Register 034h = 09, this will set ADC_MUX with 0x1001.
  2. Register 11Eh = 60, this will set MON_A9_IDX with index 6.
  3. Register 034h = 19, this will trigger manual measurement.
  4. The ADC_RES_H Register will contain the upper eight bits of the 10 bit result; register 38 will read 8F which is 10001111.   
  5. The ADC_RES_L Register will contain the 2 LSB (Least significant bits), Register 37 will read 0.
  6. Merge both ADC_RES_H and ADC_RES_L, this will give 1000111100, convert to decimal to get 572, and times by 4.883 mV.

 

I used the GUI with a standard I2C interface for read and write commands, I did not use any of its other functions or alter any other register value. I also tested all three ADC channels with different regulators and didnt have any issues. 

 

Kind Regards,

Elliott Dexter 

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
 

 

Hello Pierre-Olivier,

A potential reason why you might be getting ADC_RES_H and ADC_RES_L registers full of high bits (OxFF), is that the regulator you are trying to measure is not enabled. I re-tried the manual measurements with the regulator dis-enabled and got the same result as you, but when I enabled the regulator, the ADC measured the correct output voltage of the regulator.

Kind Regards,

Elliott Dexter

pinkpr
Offline
Last seen: 1 year 1 week ago
Joined: 2017-11-14 08:34
Hi Elliott

Hi Elliott

I finally found out what was the problem.
I probed the I2C lines with an oscilloscope and found out that no write action we done on MON_REG_5 and MON_REG_6.
I was actually using the regmap_write function of the Linux Kernel. This function verifies that the register you try to write in actually exists.
I don't know why, but the DA9063 Linux Driver register ranges was NOT including MON_REG_5 and MON_REG_6.
I just extended the register range to MON_REG_6 and everything worked.

I'll maybe submit a patch to the Linux Driver once everything will be clean.

Thank you very much for the time you allocated to help me :-)

PinkPR

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
Hello Pierre-Olivier,

Hello Pierre-Olivier,

 

No problem, happy to help..

 

Kind Regards,

Elliott Dexter 

ED_Dialog
Offline
Last seen: 18 hours 31 min ago
Staff
Joined: 2017-09-18 11:54
Hi Pierre-Oliver,

Hi Pierre-Oliver,

I have spoken with the Driver applications team about your last question, response below:

 

"Since Linux mainline v3.16-rc1 the DA9063 Linux device driver has used the standard Linux regmap framework to access the PMIC’s registers.

Regmap is a common approach for register I/O and is typically used by device drivers within the Linux kernel to perform these standard access operations. However, regmap is different compared to other operating system I/O methods. Part of the differences is due to the use of register access permission tables which regmap uses to create a chip model.

The DA9063 device driver defines register access permissions to list all possible I2C accesses to the DA9063 PMIC registers based upon pre-defined tables built into the device driver. These tables hold register -> {readable, writable, volatile} mappings and are statically defined in the file drivers/mfd/da9063-i2c.c. The Linux kernel regmap core I/O functions can therefore restrict any PMIC register accesses according to the permissions coded into these tables.

Care should be taken. When adding new functionality in Linux device drivers which will use the Linux core regmap functions to access registers: the relevant regmap access tables should be updated accordingly. If adding a new component to an existing regmap enabled device driver, each bit in every new register to be accessed should be carefully considered when formulating the register's access permission entry. The reasons for using regmap are not just to enforce register access restrictions; performance improvements, default values and simplifications to suspend and resume operations are also part of the regmap design."

 

Kind regards,

Elliott Dexter