We are working on external RTC MCP7940(i2c) interfaced with nrf52840. Please check if drivers of the same for nrf52/51 are available or any implementation of CLOCK using MCP7940 with NRF?
Regards
Vishal Aditya
Embedded Software Engineer
We are working on external RTC MCP7940(i2c) interfaced with nrf52840. Please check if drivers of the same for nrf52/51 are available or any implementation of CLOCK using MCP7940 with NRF?
Regards
Vishal Aditya
Embedded Software Engineer
HI Vishal,
I am afraid that we do not have any dedicated drivers from the MCP7940. I am also not aware of any customers that have used the MCP7940 as the 32kHz clock source for the nRF5x series, but Ithink it should be possible.
We have TWI hardware drivers in our nRF5 SDK for the nRF51 and 52 series, see Driver support matrix.
Best regards
Bjørn
bjorn-spockeli
I am writing drivers by myself & stuck in the first step of I2C DETECT not happening.
SDK: nRF5_SDK_15.2.0_9412b96\examples\peripheral\twi_scanner
MCP7940 Break-out: https://rheingoldheavy.com/product/breakout-board-mcp7940/ which works perfectly with Arduino at I2C Address: 0x6F
But I2C DETECT not working with nrf52840 DK. Please suggest how to debug this issue? We have an Oscilloscope!
HI Vishal,
I assume that the above trace is the address byte being transferred. If the MCP7940 has 0x6F as its TWI address, then you should expect to see 0b1101111, hten a READ bit followed by a ACK bit( SDA held low). From the first video, Scope of NRF52840 connected on I2C to MCP7940(Not Working), then I see 0b1101111 being sendt followed by a READ bit and then I think I see a ACK from the MCP7940, but I am not sure as I am only able to see if there are 8 or 9 CLK pulses before SDA is pulled high.Can you try to capture the entire TWI frame on the screen, i.e. 9 clk cycles on screen at the time? However, it would appear that the nRF52840 is just sending the 0x6F address and then issues a STOP condition as SDA goes high after SCL. It should wait for data from the MCP7940 by holding the CLK low, and then allow the MCP7940 to drive the clock line.
Best regards
Bjørn
// for (address = 1; address <= TWI_ADDRESSES; address++) // { while(1) { err_code = nrf_drv_twi_rx(&m_twi, 0x6F, &sample_data, sizeof(sample_data)); if (err_code == NRF_SUCCESS) { detected_device = true; NRF_LOG_INFO("TWI device detected at address 0x%x.\r\n", address); } NRF_LOG_FLUSH(); }
please check if this works for you? Let me know if a logic analyzer is required?
bjorn , can u pls. check the codes for mcp7940 and help in resolving
The screenshot showing nine clock pulses show that the slave does not ACK the address as the SDA line is high on the 9th clock pulse, you should also see nrf_drv_twi_rx returning NRF_ERROR_DRV_TWI_ERR_ANACK.
The nRF is correctly transmitting 0b11011111( 7 bit address 1101111 followed by the read bit set to 1) and then on the 9th clock pulse the MCP7940 is not pulling the SDA lin low to ACK the address transmission.
THANKS. what is the solution
THANKS. what is the solution
As far as I can see the nRF52840 is transmitting the correct sequence, its the TWI slave that must ACK by pulling SDA low during the last bit. Is nrf_drv_twi_rx returning NRF_ERROR_DRV_TWI_ERR_ANACK?
If you have access to a logic analyzer, then it would be useful to see a logic trace, just to verify that the oscilloscope measurements are correct.
Please check attached Logic Analyzer traces:
2 MHz, 10 M Samples [7].logicdata
Please check & reply to a possible solution?
AS far as I can tell the nRF52840 is transmitting the correct data. If the address of the i2C slave is 0x6F (0b01101111), then the 7 byte address + a READ bit will be 0xDF( 0b11011111). The logic analyzer clearly states that there is a NAK after the address is transmitted. Hence, this is slave issue, not an issue with the nRF52840. I would check the connections between the nRF52840 and the MCP7940.
Best regards
Bjørn
The connections are correct!
#define SCL NRF_GPIO_PIN_MAP(0,14)
#define SDA NRF_GPIO_PIN_MAP(0,13)
Connected to the same as per code via jumper wires. Please suggest any other possible way of debugging this issue. As MCP7940 works with Arduino(i2c scanner)
Please check the traces of the custom board nrf52840 & MCP7940(i2c) with the same code.
Pull-ups: 4.7kohm in custom board
but in MCP7940 break-out board, it's 10kohm
#define SCL NRF_GPIO_PIN_MAP(0,14) #define SDA NRF_GPIO_PIN_MAP(0,13) // for (address = 1; address <= TWI_ADDRESSES; address++) // { while(1) { err_code = nrf_drv_twi_rx(&m_twi, 0x6F, &sample_data, sizeof(sample_data)); if (err_code == NRF_SUCCESS) { detected_device = true; NRF_LOG_INFO("TWI device detected at address 0x%x.\r\n", address); } NRF_LOG_FLUSH(); }