I trying to move the SPI bus on a Raspberry Pi 3. I would like to move it from GPIO 7-11 to GPIO pins 22-26. The file "bcm2708_common.dtsi" contains the node for the spi0 bus:
spi0: spi#7e204000 {
compatible = "brcm,bcm2835-spi";
reg = <0x7e204000 0x1000>;
interrupts = <2 22>;
clocks = <&clk_core>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
/* the dma channels */
dmas = <&dma 6>, <&dma 7>;
dma-names = "tx", "rx";
/* the chipselects used - <0> means native GPIO
* add more gpios if necessary as <&gpio 6 1>
* (but do not forget to make them output!)
*/
cs-gpios = <0>, <0>;
};
The spi is configured in the top-level dts file "bcm2710-rpi-3-b.dts":
&gpio {
spi0_pins: spi0_pins {
brcm,pins = <7 8 9 10 11>;
brcm,function = <4>; /* alt0 */
};
};
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
cs-gpios = <0 0>;
spidev#0{
compatible = "spidev";
reg = <0>; /* CE0 */
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <500000>;
};
spidev#1{
compatible = "spidev";
reg = <1>; /* CE1 */
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <500000>;
};
};
Is reconfiguring the spi pins as simple as changing the gpio entry to this or is there something more that I need to do?
&gpio {
spi0_pins: spi0_pins {
brcm,pins = <22 23 24 25 26>;
brcm,function = <4>; /* alt0 */
};
};
No. you can not just change the pin numbers in DTSI and get it to change.
Long answer:
The brcm,pins field is just information for driver to refer to, if hardware does not support the pins you write there, you can not get it to work. On the Rpi 3b, pins 7,8,9,10,11 are supported as SPI i.e they can be multiplexed as SPI (the field brcm,function tells which multiplex mode to set pins in).
Now, also if you search for BCM2835 ARM peripheral you will find on page 152 the following:
The BCM2835 devices has only one SPI interface of this type. It is
referred to in all the documentation as SPI0. It has two additional
mini SPI interfaces (SPI1 and SPI2). The specifiation of those can be
found under 2.3 Universal SPI Master (2x).
So, the SoC on Rpi itself does not support other spi on any other pin.
Now for the second sentence of the above quote
It has two additional mini SPI interfaces (SPI1 and SPI2). The specifiation of those > can be found under 2.3 Universal SPI Master (2x).
If you dig in to bcm283x.dtsi, you will find that both those mini spis are named SPI1 and SPI2. gpio pins assigned for them are given as spi1_gpio16 and spi2_gpio40
which use pins :
spi1_gpio16: spi1_gpio16 {
brcm,pins = <16 17 18 19 20 21>;
brcm,function = <BCM2835_FSEL_ALT4>;
};
spi2_gpio40: spi2_gpio40 {
brcm,pins = <40 41 42 43 44 45>;
brcm,function = <BCM2835_FSEL_ALT4>;
};
so again not the pins you want to use.
You may go for bit banging spi if you are really really in a fix and can not use anything else
Related
I ask it here to check if my guess is correct.
This page says
Currently we have devm_clk_get() which gives a managed-resource clk
(by name), or of_clk_get() which gives an unmanaged resource clk (by
id).
So I guess clk_get is selecting the clock using 'clock-names' (which is input to a clock consumer device) in the device tree, and of_clk_get is for selecting the clock using 'clock id' (which is the first number in the index-name pair of the clock input specifier.
And I see these lines in a driver drivers/tty/serial/bcm63xx_uart.c (linux 5.15.68).
clk = clk_get(&pdev->dev, "refclk"); // first try
if (IS_ERR(clk) && pdev->dev.of_node)
clk = of_clk_get(pdev->dev.of_node, 0); // second try
It looks like it first try to get the input clock from the name "refclk" and if it fails, it trys to get the clock from the clock speicifer, 0 meaning the first input clock. Is my understanding correct? Are both tries using device tree information?
I see in arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi,
clocks {
periph_clk: periph_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <50000000>;
clock-output-names = "periph";
};
};
uart0: serial#640 {
compatible = "brcm,bcm6345-uart";
reg = <0x640 0x18>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&periph_clk>;
clock-names = "refclk";
status = "okay";
};
I have got a problem with an electronic board based on a TSM32L4xx microcontroler.
I am using HAL driver for all peripherals initilization.
I use USART3 to communicate in RS232 with a computer
When the microcontroler rise under -6°C (in a freeze), the transmission on the microcontroler works, but not the reception (interruption doesn't rise).
The USART is initialized with SYSCLOCK :
void HAL_UART_MspInit(UART_HandleTypeDef *huart)
{
[...]
USARTx_RCC_CONFIG(RCC_USART3CLKSOURCE_SYSCLK);
[...]
}
I read that under 0°C the PLL can stop to work but I don't use it...
Here is my System Clock initialisation :
void InitSystemClock(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
RCC_PeriphCLKInitTypeDef PeriphClkInit;
RCC_OSCILLATORTYPE_MSI|RCC_OSCILLATORTYPE_LSE;
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI
| RCC_OSCILLATORTYPE_MSI
| RCC_OSCILLATORTYPE_LSE;
RCC_OscInitStruct.LSEState = RCC_LSE_ON;
RCC_OscInitStruct.MSIState = RCC_MSI_ON;
RCC_OscInitStruct.MSICalibrationValue = 0;
RCC_OscInitStruct.MSIClockRange = CLOCK_RANGE;
RCC_OscInitStruct.HSIState = RCC_HSI_OFF;
RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_OFF;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
| RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_MSI;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0);
PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_RTC;
PeriphClkInit.RTCClockSelection = RCC_RTCCLKSOURCE_LSE;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit);
__HAL_RCC_PWR_CLK_ENABLE();
HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1);
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
DWT->CTRL |= 1; //CYCCNTENA
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
/* SysTick_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
/* GPIO Ports Clock Enable */
__GPIOA_CLK_ENABLE();
__GPIOB_CLK_ENABLE();
__GPIOC_CLK_ENABLE();
__GPIOD_CLK_ENABLE();
__GPIOE_CLK_ENABLE();
}
Edit :
I made an interresting test :
I've configured a PWM (using timer2 channel 3 and 4).
The PWM generates a 375Hz frequency.
After putting the electronic board into the freezer, the PWM decrease to 345Hz at -18°C
I made the measures with a laboratory oscilloscope
Anyone has encountered this issue ?
Anyone has got an idea about this problem ?
Thanks a lot by advance,
Baptiste
Assuming you are using the USART as UART:
If you have an accurate reference frequency such as LSE, you could perform a RC calibration according to the temperature, see the RCC_ICSCR register. An internal temperature sensor is available.
This application note shows how to calibrate the internal RCs.
At 30°C, the HSI16 oscillator has an accuracy of ±0.5%, the MSI
oscillator has an accuracy of ± 0.6% and the HSI48 oscillator has an
accuracy of ±4%. But in the temperature range of -40°C to 105°C, the
accuracy decreases.
UARTs are very sensitive to the clock variations especially if you send more data in one go.
You need to use crystal oscillator with good temperature stability or send very small chunks of data or check the internal temperature sensor and change the baud settings accordingly
I have compiled an image with buildroot. I want to work with I2C2 which is located in P9.19 and P9.20 ( SCL and SDA). I have connected the BBB I2C2 to a kw40z - NXP controller. I have added pull up to SDA and SCL, shared ground and connected both SCL and SDA to each other. I do see /dev/i2c-2
I2C2 does not work. I tried i2cdetect -r 2 and also a C program but I am getting timeout.
My questions are:
Does I2C2 is enabled or should I add the I2C2 device tree overlay from here:
If so, I compile the above dts fragment into dtbo ( using the dtc compiler)
How do i tell buildroot in beagle bone to load that dtbo?
I read that buildroot and even Debian does not support cape manager.
So it should be static.
Does any one managed to work with I2C2 without overlay? or is it a must?
Thanks!
Problem solved for i2c1 and i2c2
I added the two fragments into the bone-common.dtsi
for both I2C1 and I2C2 ( this is I2C1 for example)
under the pin mux
&am33xx_pinmux {
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins = <
0x158 (SLEWCTRL_SLOW | PIN_INPUT_PULLUP | MUX_MODE2) /* i2c1_sda */
0x15c (SLEWCTRL_SLOW | PIN_INPUT_PULLUP | MUX_MODE2) /*i2c1_scl */>;
};
And the node itself in am335x-boneblack.dts
&i2c1 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
/* this is the configuration part */
clock-frequency = <100000>;
#address-cells = <1>;
#size-cells = <0>;
};
Also , no need for external pull-up when its is internally of course.
The pins are 17 - scl and 18 sda
I am trying to drive a EEPROM Chip 25LC256 with a STM32F469I-DISCO but can't achieve it.
I have tried to make my own function with HAL API bases but apparently something is wrong : I don't know if I write datas on the chip since I can't read it. Let me explain more.
So my chip is a DIP 25LC256 (DS is above is you wish). PINs HOLD and WP of EEPROM are tied to VCC (3.3V). PIN CS is connected to PH6 (ARD_D10 on board) and is managed by the software. PIN SI and PIN SO are respectively connected to PB15 (ARD_D11) and PB14 (ARD_D12) with the right alternate function (GPIO_AF5_SPI2). PIN SCK is also connected to PD3 (ADR_D13).
Here is my SPI configuration code :
EEPROM_StatusTypeDef ConfigurationSPI2(SPI_HandleTypeDef *spi2Handle){
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();
__HAL_RCC_GPIOH_CLK_ENABLE();
GPIO_InitTypeDef gpioInit;
//// SCK [PD3]
gpioInit.Pin = GPIO_PIN_3;
gpioInit.Mode = GPIO_MODE_AF_PP;
gpioInit.Pull = GPIO_PULLDOWN;
gpioInit.Speed = GPIO_SPEED_FREQ_HIGH;
gpioInit.Alternate = GPIO_AF5_SPI2;
HAL_GPIO_Init(GPIOD, &gpioInit);
//// MOSI [PB15]
gpioInit.Pin = GPIO_PIN_15;
gpioInit.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOB, &gpioInit);
//// MISO [PB14]
gpioInit.Pin = GPIO_PIN_14;
gpioInit.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOB, &gpioInit);
//// CS [PH6]
gpioInit.Pin = GPIO_PIN_6;
gpioInit.Mode = GPIO_MODE_OUTPUT_PP;
gpioInit.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOH, &gpioInit);
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, GPIO_PIN_SET);
//// SPI2
__HAL_RCC_SPI2_CLK_ENABLE();
spi2Handle->Instance = SPI2;
spi2Handle->Init.Mode = SPI_MODE_MASTER;
spi2Handle->Init.Direction = SPI_DIRECTION_2LINES;
spi2Handle->Init.DataSize = SPI_DATASIZE_8BIT;
spi2Handle->Init.CLKPolarity = SPI_POLARITY_LOW;
spi2Handle->Init.CLKPhase = SPI_PHASE_1EDGE;
spi2Handle->Init.NSS = SPI_NSS_SOFT;
spi2Handle->Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;
spi2Handle->Init.FirstBit = SPI_FIRSTBIT_MSB;
spi2Handle->Init.TIMode = SPI_TIMODE_DISABLE;
spi2Handle->Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE ;
spi2Handle->Init.CRCPolynomial = 7;
if(HAL_SPI_Init(spi2Handle) != HAL_OK){
return EEPROM_ERROR;
}
return EEPROM_OK;
}
And two functions allowing respectively (and theorically) to WRITE and READ into the the chip :
Write Function :
EEPROM_StatusTypeDef WriteEEPROM(SPI_HandleTypeDef *spi2Handle, uint8_t *txBuffer, uint16_t size, uint16_t addr){
uint8_t addrLow = addr & 0xFF;
uint8_t addrHigh = (addr >> 8);
uint8_t wrenInstruction = WREN_EEPROM; // Value : 0x06
uint8_t buffer[32] = {WRITE_EEPROM, addrHigh, addrLow}; //Value : 0x02
for(uint i = 0 ; i < size ; i++){
buffer[3+i] = txBuffer[i];
}
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, RESET);
if(HAL_SPI_Transmit(spi2Handle, &wrenInstruction, 1, TIMEOUT_EEPROM) != HAL_OK){
return EEPROM_ERROR;;
}
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, SET);
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, RESET);
if(HAL_SPI_Transmit(spi2Handle, buffer, (size + 3), TIMEOUT_EEPROM) != HAL_OK){
return EEPROM_ERROR;
}
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, SET);
return EEPROM_OK;
}
Read Function :
EEPROM_StatusTypeDef ReadEEPROM(SPI_HandleTypeDef *spi2Handle, uint8_t *rxBuffer, uint16_t size, uint16_t addr){
uint8_t addrLow = addr & 0xFF;
uint8_t addrHigh = (addr >> 8);
uint8_t txBuffer[3] = {READ_EEPROM, addrHigh, addrLow};
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, RESET);
HAL_SPI_Transmit(spi2Handle, txBuffer, 3, TIMEOUT_EEPROM);
HAL_SPI_Receive(spi2Handle, rxBuffer, size, TIMEOUT_EEPROM);
HAL_GPIO_WritePin(GPIOH, GPIO_PIN_6, SET);
return EEPROM_OK;
}
I know my function are not very "beautiful" but it was a first attempt. In my main, I have tried in the first place to write into the chip the data "0x05" at the 0x01 adress then to read this data back :
uint8_t bufferEEPROM[1] = {5};
uint8_t bufferEEPROM2[1] = {1};
WriteEEPROM(&spi2Handle, bufferEEPROM, 1, 0x01);
ReadEEPROM(&spi2Handle, bufferEEPROM2, 1, 0x01);
I have an oscilloscope so since it didn't work (monitoring with STM Studio) I visualized the CLK and SI PINs then CLK and SO PINs (can only see two channel at the same time) :
As you can see, with the first picture that shows CLK (yellow) and SI (or MOSI) in blue, I have all the data expected : The WRite ENable instruction then the WRITE instruction. Following the ADDRESS, then the DATA.
After that, the Read Function starts. First the READ instruction and the ADDRESS where I want to fetch the data. The last 8 bits are supposed to be the data stored at the address (0x01 in this case). Something happens on SI PIN but I guess this is because the HAL_SPI_Receive() function actually calls HAL_SPI_TransmitReceive() with my array bufferEEPROM2 as parameter (that's why we can se 0b00000001). And so it is because of my SPI configuration parameter (Full-duplex).
Anyway, theorically I am supposed to see 0b00000101 on SO PIN but as you can see in the second picture.... nothing.
I have tried to change gpioInit.Pull for SO PIN on PULLUP and PULLDOWN but nothing changed. NOPULL is because that's the last thing I have tried.
The thing is I don't know where to start. My transmission seems to work (but is it actually ?). Is there anything wrong with my initialization ? Acutally my main question would be : why I don't receive any data from my EEPROM ?
Many thanks !
Write operations need some time to complete (your datasheet says 5 ms on page 4), during that time no operation other than read status is possible. Try polling the status register with the RDSR (0x05) opcode to find out when it becomes ready (bit 0). You could also check the status (bit 1) before and after issuing WREN to see if it was successful.
So the problem is now solved. Here are the improvements :
There was actually two issues. The first one and certainly the most important is, as berendi stated, a timing issue. In my WRITE function I didn't let the time for the EEPROM to complete its write cycle (5 ms on datasheet). I added the following code line at the end of all my WRITE functions :
HAL_Delay(10); //10 ms wait for the EEPROM to complete the write cycle
The delay value could be less I think if time is preicous (theorically 5ms). I didn't test below 10 ms though. An other thing. With the oscilloscope I also saw that my Chip Select used to went HIGH in the middle of my last clock edge. I could not say if this could also imply some issues since that's a thing I solved in the first place by adding a code line before HAl_Delay(10). All my SPI transmission functions finishes this way now :
while(HAL_GPIO_ReadPin(CLK_PORT, CLK_PIN) == GPIO_PIN_SET){
}
HAL_GPIO_WritePin(CS_PORT, CS_PIN, GPIO_PIN_SET);
HAL_Delay(10);
This way I have the proper pattern and I can write in the EEPROM and read back what I wrote.
NB : A last thing that made me goes deeper into my misunderstanding of the events : since my write functions didn't work, I focused on STATUS REGISTER write and read function (in order to solve this step by step). The write function didn't work either and in fact it was because the WRENbit wasn't set. I though (wrong one) that the fact to write into the STATUS REGISTER didn't ask also to set WREN like the WRITE functions into the memory ask to. Actually, it is also necessary.
Thanks for the help !
I am a new to stm32f103c8t6. Now I am trying to learn the SPI function and finished the code from the RCC to SPI initialization. I used oscilloscope to measure the SPI1 SCK signal due to test equipment limitation. Indeed that is clock signal but much lower than my RCC configuration. I tried to search the reason, but still failed. So may I ask if someone knows the answer.
RCC_DeInit();
RCC_HSEConfig(RCC_HSE_ON);
Errsts = RCC_WaitForHSEStartUp();
if (Errsts == SUCCESS)
{
FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);
RCC_PLLConfig(RCC_PLLSource_HSE_Div2, RCC_PLLMul_9);
RCC_PLLCmd(ENABLE);
while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY == RESET))
{
}
FLASH_SetLatency(FLASH_Latency_1);
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
RCC_HCLKConfig(RCC_SYSCLK_Div1);
RCC_PCLK1Config(RCC_HCLK_Div2);
RCC_PCLK2Config(RCC_HCLK_Div1);
while (RCC_GetSYSCLKSource() != 0x08)
{
}
}
The code above shows my configuration about RCC, I used HSE as clock and the final frequency is 8Mhz/2*9=36Mhz. Below is my SPI and GPIO initialization:
SPI_InitTypeDef SPI_InitStructure;
GPIO_InitTypeDef GPIO_InitStructure;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5| GPIO_Pin_6| GPIO_Pin_7;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_10MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_10MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_WriteBit(GPIOA, GPIO_Pin_4,Bit_SET);
SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low;
SPI_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_4;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitStructure);
/* Enable SPI2 */
SPI_Cmd(SPI1, ENABLE);
So SPI_BaudRatePrescaler=4 means my SPI clock is 36Mhz/4=9Mhz, but actually the oscilloscope shows the frequecy is around 200Khz, it is much lower the the expectation. Also I tried to config SPI_BaudRatePrescaler with different value, it seems that the outcome is not linear.
Therefore I would like to ask if someone knows the answer. Thanks a lot!
Double check your prescaler value in your configuration. According to the reference manual, a value of 4 in the baud rate field will result in a divider of 32. To get to a clock of around 200 kHz, you need a value in that register of 6 or 7, which results in a divider of 128 or 256 (281 kHz or 140 kHz). If you want a divider of 4, you'll need to put a value of 1 in there. Check and see if SPI_BaudRatePrescaler_4 results in a value of 4 in the register, or a value of 1.
The outcome is not linear because they are using it as an exponent of 2. A value of 0 is 2^(0+1), while 1 is 2^(1+1), etc, etc.