Connecting STM32F4Discovery & AT86RF233

Development archive
1

Hi all,

I am struggling a bit to understand how to connect my STM32F4Discovery board with my AT86RF233 ZigBit Xplained Pro Extension board (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx). I have a few questions that I list as follows:-

· When connecting the SPI interface, is it enough to connect SCK, MISO and MOSI? Or should I also connect SS?

· I see that the file https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_params.h has some PIN configuration parameters. What is AT86RF2XX_PARAM_CS? Looking at the manual for my AT86RF233 board (http://www.atmel.com/Images/Atmel-Wireless-ATZB-X-233-XPRO_design_documentation.PDF), on page 3 I see the RESET (AT86RF2XX_PARAM_RESET), SLP_TR (AT86RF2XX_PARAM_SLEEP) and the IRQ (AT86RF2XX_PARAM_INT) pins. I do not seem to find the corresponding pin for AT86RF2XX_PARAM_CS. Any clues?

· Should I include anything besides USEMODULE += at86rf2xx to be able to use the transceiver?

Regards,

Adeel

2

Hi Adeel,

please see my answers inline. I hope this helps, let us know if there is further open questions.

Best, Thomas

Hi all,

I am struggling a bit to understand how to connect my STM32F4Discovery board with my AT86RF233 ZigBit Xplained Pro Extension board (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx). I have a few questions that I list as follows:-

* When connecting the SPI interface, is it enough to connect SCK, MISO and MOSI? Or should I also connect SS?

What you refer to as SS (Slave Select) is called CS (Chip Select) in RIOT. So yes, you have to connect this pin too to actually activate the slave's SPI interface.

* I see that the file RIOT/drivers/at86rf2xx/include/at86rf2xx_params.h at master · RIOT-OS/RIOT · GitHub has some PIN configuration parameters. What is AT86RF2XX_PARAM_CS? Looking at the manual for my AT86RF233 board (http://www.atmel.com/Images/Atmel-Wireless-ATZB-X-233-XPRO_design_documentation.PDF), on page 3 I see the RESET (AT86RF2XX_PARAM_RESET), SLP_TR (AT86RF2XX_PARAM_SLEEP) and the IRQ (AT86RF2XX_PARAM_INT) pins. I do not seem to find the corresponding pin for AT86RF2XX_PARAM_CS. Any clues?

See above.

* Should I include anything besides USEMODULE += at86rf2xx to be able to use the transceiver?

In your particular case you will want to include `USEMODULE += at86rf233`.

3

Hi Thomas,

I did as you said. I have 9 wires connected between my STM32F4Discovery board and the AT86RF233 ZigBit Xplained Pro Extension board. 4 SPI wires, 3 GPIO wires and 2 for power (+3.3V and GND).

Now doing an "ifconfig" gives me the following result:-

ifconfig Iface 3 HWaddr: 00:00 Channel: 0 Page: 0 NID: 0x0            Long HWaddr: 00:00:00:00:00:00:00:00            TX-Power: -17dBm State: IDLE max. Retrans.: 15                        Source address length: 2             Iface 4 HWaddr: 00:15:01:00:40:e4                        Source address length: 6

I was expecting to see a valid HWaddr but this doesn't look right. Should I be able to see a HWaddr if the connection is alright?

/Adeel

4

Hi Adeel,

the transceiver uses the cpuid module to generate hwaddr. If your port is based on the stm32f4discovery board it should be configured already which makes me think there might still be some nit in your SPI connection.

You could try to issue `ifconfig set addr <your_addr>`. If you then do `ifconfig` again and nothing changed I guess it would be the SPI connection. Else you might miss some configuration still.

Best, Thomas

5

Hi,

just as a side note: @Nordzisko has a pretty similar setup wich worked (except the button issue)

https://github.com/RIOT-OS/RIOT/issues/5407

Best Peter

6

Hi Peter and Thomas,

I was quite skeptical about my pin connections/configurations. I did realize that the default pin mapping of the Atmel driver could be a problem so I had already defined my own pin mapping in the file "/boards/stm32f4discovery/include/board.h" before writing to the mailing list. I defined it as follows:-

#define AT86RF2XX_PARAMS_BOARD {   .spi = SPI_0, \   .spi_speed = SPI_SPEED_5MHZ, \   .cs_pin = GPIO_PIN(PORT_A, 0), \   .int_pin = GPIO_PIN(PORT_E, 0), \   .sleep_pin = GPIO_PIN(PORT_E, 1), \   .reset_pin = GPIO_PIN(PORT_E, 2)}

After reading the thread that Peter referred to, I checked the file "/boards/stm32f4discovery/include/board.h" and saw that there is an overlap on PA0:-

#define BTN_B1_PIN GPIO_PIN(PORT_A, 0)

The reason I defined AT86RF2XX_PARAMS_BOARD as above is the link https://github.com/RIOT-OS/RIOT/wiki/Board%3A-STM32F4discovery where a picture of the STM32F4DISCOVERY board shows the different pins. I just assumed that GPIO_0 (PA0), GPIO_1 (PE0), GPIO_2 (PE1), GPIO_3 (PE2), as shown in the picture, are not connected to anything and hence free to use. My assumption was obviously wrong.

I will fix my pin configuration tomorrow and see if it works for me. Thanks for your replies. You guys are really helpful.

Regards, Adeel

7

Adeel,

we're happy to help and please keep us posted about your progress.

Best, Thomas

8

Hi again,

I just used the following pin configuration for the AT86RF233 transceiver now:-

#define AT86RF2XX_PARAMS_BOARD {   .spi = SPI_0, \   .spi_speed = SPI_SPEED_5MHZ, \   .cs_pin = GPIO_PIN(PORT_E, 0), \   .int_pin = GPIO_PIN(PORT_E, 1), \   .sleep_pin = GPIO_PIN(PORT_E, 2), \   .reset_pin = GPIO_PIN(PORT_E, 3)}

I still have the same problem. I have the following relevant modules included in my Makefile:-

... USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif GNRC_NETIF_NUMOF := 2 USEMODULE += ethos gnrc_netdev2 CFLAGS += '-DETHOS_UART=UART_DEV(0)' -DETHOS_BAUDRATE=115200 -DUSE_ETHOS_FOR_STDIO USEMODULE += at86rf233 ...

Any hints/clues would be appreciated.

/Adeel

9

Hi again,

I think I got the SPI connection right now. I just configured an address using ifconfig and was able to change the address. I am still not getting an address automatically which as Thomas mentioned I should be getting using the cupid module. Seems like I am missing a module in my Makefile.

/Adeel

10

Hi Adeel,

generation of the CPUID shouldn't be a problem. I checked it on an stm32f4discovery board. Can you try it with examples/gnrc_networking? "ifconfig" works there as well.

The f4 board usually has no network interface and now you're about to initialize two. I could imagine it's just a configuration problem but to be sure, please check gnrc_networking first.

Best Peter

11

Hi Peter,

Do you mean I should get an address on my interface without having to configure it manually? If so, which module (USEMODULE) is it exactly that has this effect?

/Adeel

12

Hi Adeel,

not sure I fully understand you previous mail. The driver will generate a default hardware address which is based on the CPUID.

USEMODULE += at86rf233

AFAIK one of these modules is actually responsible for that

USEMODULE += gnrc_netdev_default USEMODULE += auto_init_gnrc_netif

You already have this in. Otherwise there won't be any hardware access. If you try examples/gnrc_networking (maybe at first in native) and type "ifconfig" you will see that the network interface has some ipv6 addresses. The local unicast address is based on the hardware address which was explained previously.

I currently don't know which module attaches these ip addresses, maybe @miri64 can say more? Anyway, please try to get the transceiver running with tests/driver_at86rf2xx and examples/gnrc_networking before using it on a border router.

Best Peter

13

Hi again,

I was talking about the HWaddr. I want to run the CCN stack directly over the radio without any IP stack. Does the CPUID module also configure the hardware addresses?

/Adeel

14

Hi,

as said, the radio driver uses the CPUID for hardware address generation, so yes. See this line and following:

https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L77

Best Peter

15

Hi Peter,

What PIN configuration do you use with AT86RF233? I went through the thread https://github.com/RIOT-OS/RIOT/issues/5407. You use PA2 for RESET. I want to use PA2 for UART TX. I keep my config same as yours except that I use PE2 for RESET.

I still have problems with my SPI connection I presume. I debugged my code and I get a problem here https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L85. The part number is 0xff. It does not match with AT86RF233_PARTNUM (0x0b) defined here https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/include/at86rf2xx_registers.h#L38.

/Adeel

16

Hi again,

By the way, I bought the ATZB-X-233-XPRO module (http://www.atmel.com/tools/ATZB-X-233-XPRO.aspx?tab=overview) and not ATZB-A-233-XPRO (http://www.atmel.com/tools/ATZB-A-233-XPRO.aspx?tab=overview). This could possibly be the problem.

/Adeel

17

Hi Adeel,

please note that issue #5407 is about the F3 discovery so the pin configuration might differ. I connected an openlabs transceiver

http://openlabs.co/OSHW/Raspberry-Pi-802.15.4-radio

(basically containing an Atmel AT86RF233) to the stm32f4discovery. This is the configuration that I have used

https://github.com/PeterKietzmann/RIOT/tree/stm32f4discovery_add_at86rf233_config

examples/gnrc_networking worked as expected. Could you take that branch, connect your device accordingly and try gnrc_networking again?

I currently don't find the time to look into the details of that device but the ATZB-A-233-XPRO basically worked for @Nordziski and from what you describe I have the impression it is a peripheral problem. Do you have a logic analyser to see what is on the SPI bus and the additional pins?

I experienced the usage of these cheap jumper cables as a big source of trouble pretty often...

Best regards Peter

18

Hi Peter,

I tried the branch you referred to. I still face the same issue. My guess is that ATZB-X-233-XPRO is a bit different from ATZB-A-233-XPRO in terms of pin configurations.

Unfortunately I do not have a logic analyzer. If cheap jumper cables can be a problem, then this can get a bit hard to troubleshoot.

/Adeel

19

Hey,

I asked @Nordzisko for advice.

https://github.com/RIOT-OS/RIOT/issues/5407#issuecomment-237543456

As said, I currently won't find time to study the hardware in detail. But I'm pretty convinced that your problems are about configuring the driver or maybe the device itself.

About the jumper cables: They do work :slight_smile: but I often had loose connections, broken plugs and also confused connections myself. So just be careful ;-).

Best Peter

20

Hi Adeel,

you could try to add a printf() in the `spi_transfer_byte` function in stm32f4/periph/spi.c for the `in` pointer and see if there are reasonable values shown - to make sure SPI communication is working.

Best, Thomas