Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[WIP] cpu/cc26x2_cc13x2: add sub-ghz driver #18737

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

[WIP] cpu/cc26x2_cc13x2: add sub-ghz driver #18737

wants to merge 11 commits into from
+4,135 −37

Conversation

kYc0o
Copy link
Contributor

@kYc0o kYc0o commented Oct 13, 2022

Contribution description

This PR is a continued work on #13295 from @jeandudey. Basically it retakes the same features and code, I just updated it and adapted it for the current API and HAL.

Testing procedure

For now some warnings are being triggered, I'm working on them but I think it will take me a while to remove them, although the code compiles and works with the following command:

$ BOARD=cc1312-launchpad WERROR=0 make -C examples/gnrc_networking flash term

I only tested on 2 cc1312-launchpad boards, I'd need to get some other supported sub-ghz board to check broad compatibility.

Issues/PRs references

#13295
#13205
#13215

jeandudey and others added 11 commits October 13, 2022 18:21
@jeandudey @kYc0o
cc26xx_cc13xx: add functions to toggle RFC clocks
0899425 
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
cc26xx_cc13xx: add RF Core definitions
f80e9ce 
This adds the necessary structures to communicate with the RF Core.

Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
cc26x2_cc13x2: add vendor CPE patch for prop phy
82be9a6 
This is a patch distributed on the TI SDK for the Command and Packet
Engine when the mode is the propietary PHY layer.

Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
net/netdev: create CC26XX/CC13xx entry in netdev_type_t
26070f3 
Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
@jeandudey @kYc0o
cc26x2_cc13x2: add cc26x2_cc13x2_rf driver
aeea65d 
This driver implements the ieee802154_hal interface.

Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
init_devs: add cc26x2_cc13x2_rf network device
612e6e6 
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
cc1312-launchpad: add cc26x2_cc13x2_rf netif
bfe391d 
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
cc1352p-launchpad: add cc26x2_cc13x2_rf netif
25064a7 
Signed-off-by: Jean Pierre Dudey <jeandudey@hotmail.com>
@jeandudey @kYc0o
cc1352-launchpad: add cc26x2_cc13x2_rf netif
24fdddb 
Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
@jeandudey @kYc0o
tests/ieee802154_hal: add cc26x2_cc13x2_rf
f60b20a 
Also whitelisted the boards that support the `cc26x2_cc13x2_rf`
IEEE 802.15.4g Sub-GHz radio.

Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
@jeandudey @kYc0o
tests/ieee802154_submac: whitelist cc26x2_cc13x2_rf boards
8a0bef8 
Signed-off-by: Jean Pierre Dudey <me@jeandudey.tech>
@github-actions github-actions bot added Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports Area: drivers Area: Device drivers Area: network Area: Networking Area: sys Area: System Area: tests Area: tests and testing framework Platform: ARM Platform: This PR/issue effects ARM-based platforms labels Oct 13, 2022
@kYc0o kYc0o changed the title Pr/add cc26x2 cc13x2 radio [WIP] cpu/cc26x2_cc13x2: add sub-1-ghz driver Oct 13, 2022
@kYc0o kYc0o mentioned this pull request Oct 13, 2022
Closed
@kYc0o kYc0o changed the title [WIP] cpu/cc26x2_cc13x2: add sub-1-ghz driver [WIP] cpu/cc26x2_cc13x2: add sub-ghz driver Oct 13, 2022
jeandudey
jeandudey reviewed Oct 14, 2022
View reviewed changes
cpu/cc26x2_cc13x2/include/cc26x2_cc13x2_rf_internal.h
Comment on lines +56 to +69
#define IEEE802154_SUN_PHY_FREQ_169_MHZ 0 /**< 169.400-169.475 (Europe) */
#define IEEE802154_SUN_PHY_FREQ_450_MHZ 1 /**< 450-470 (US FCC Part 22/90) */
#define IEEE802154_SUN_PHY_FREQ_470_MHZ 2 /**< 470-510 (China) */
#define IEEE802154_SUN_PHY_FREQ_780_MHZ 3 /**< 779-787 (China) */
#define IEEE802154_SUN_PHY_FREQ_863_MHZ 4 /**< 863-870 (Europe) */
#define IEEE802154_SUN_PHY_FREQ_896_MHZ 5 /**< 896-901 (US FCC Part 90) */
#define IEEE802154_SUN_PHY_FREQ_901_MHZ 6 /**< 901-902 (US FCC Part 24) */
#define IEEE802154_SUN_PHY_FREQ_915_MHZ 7 /**< 902-928 (US) */
#define IEEE802154_SUN_PHY_FREQ_917_MHZ 8 /**< 917-923.5 (Korea) */
#define IEEE802154_SUN_PHY_FREQ_920_MHZ 9 /**< 920-928 (Japan) */
#define IEEE802154_SUN_PHY_FREQ_928_MHZ 10 /**< 928-960 (US, non-contiguous) */
#define IEEE802154_SUN_PHY_FREQ_950_MHZ 11 /**< 950-958 (Japan) */
#define IEEE802154_SUN_PHY_FREQ_1427_MHZ 12 /**< 1427-1518 (US and Canada, non-contiguous) */
#define IEEE802154_SUN_PHY_FREQ_2450_MHZ 13 /**< 2400-2483.5 */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be moved to ieee802154 headers. Might be useful some day there outside of this driver if we manage to develop the descriptors present in the standard.

Don't know if @jia200x would agree on this

@SpooniSpoon
Copy link

Hi,
I would like to test the modified sub 1 ghz driver on a launchpad cc1352r1. Unfortunately I am not able to flash my launchpad due to the issue #18750.

@kYc0o
Copy link
Contributor Author

kYc0o commented Oct 17, 2022

Hi, I would like to test the modified sub 1 ghz driver on a launchpad cc1352r1. Unfortunately I am not able to flash my launchpad due to the issue #18750.

Do you have CCS or Uniflash? I'm using uniflash since I know openocd has a problem with these boards. Normally you may be able to use openocd if you have the TI version of it https://git.ti.com/cgit/sdo-emu/openocd

@SpooniSpoon
Copy link

I have ccs and uniflash installed but I failed to get uniflash invoked by the RIOT toolchain. Are you using an IDE for debugging RIOT on the launchpad or do you use only the terminal?

@kYc0o
Copy link
Contributor Author

kYc0o commented Oct 17, 2022

I have ccs and uniflash installed but I failed to get uniflash invoked by the RIOT toolchain. Are you using an IDE for debugging RIOT on the launchpad or do you use only the terminal?

No I'm using only the terminal. You may need to export the path to the uniflash binary. On my computer (a Macbook) I have this:

UNIFLASH_PATH=/Applications/ti/UniFlash/

Then RIOT detects it and use it to flash the board.

@jeandudey
Copy link
Contributor

@SpooniSpoon have you tried updating the XDS110 firmware? Using CCS or Uniflash UI can do that

@SpooniSpoon
Copy link

Thanks for the hints.

Unfortunately I am sill not able to use uniflash as a programmer. I set the PROGRAMMER and UNIFLASH_PATH environment variables. The GUI version of the uniflash tools works.

I am able to compile and program the hello world example by using the GUI version of uniflash. Therefore I think the XDS110 firmware on my launchpad is valid.

I am also able to compile the network example with some warnings as expected, but there is no terminal output at all after programming the generated *.bin file with the GUI version of uniflash.

@kYc0o
Copy link
Contributor Author

kYc0o commented Oct 21, 2022

@SpooniSpoon what's the error you have when you try to flash with uniflash? (actually is rather dslite but both are part of the uniflash software)

When I try with the default configuration I have the following error (on a cc1352-launchpad)

fatal: IcePick_C: Error initializing emulator: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed. The cause may be one or more of: no XDS110 is connected, invalid firmware update, invalid XDS110 serial number, or faulty USB cable. The firmware and serial number may be updated using the xdsdfu utility found in the .../ccs_base/common/uscif/xds110 directory of your installation. View the XDS110SupportReadMe.pdf file there for instructions. (Emulation package 9.8.0.00235) 
Failed: IcePick_C: Error initializing emulator: (Error -260 @ 0x0)
An attempt to connect to the XDS110 failed.
The cause may be one or more of: no XDS110 is connected, invalid
firmware update, invalid XDS110 serial number, or faulty USB
cable. The firmware and serial number may be updated using the
xdsdfu utility found in the .../ccs_base/common/uscif/xds110
directory of your installation. View the XDS110SupportReadMe.pdf
file there for instructions.
(Emulation package 9.8.0.00235)

However, when I change the serial number of the adaptor in the file cc1352r1_XDS110.ccxml (at boards/common/cc26xx_cc13xx/dist) from L41003KF to L41008PN it works correctly, flashes the device and after a physical reset on the board I get the prompt of the RIOT console.

Could you maybe try the same?

@CW-75
Copy link
Contributor

CW-75 commented Oct 24, 2022 •
edited
Loading

Hello, I tried to maintain continuous communication on two cc1312-launchpad boards and got the following error...

2022-10-24 00:48:52,270 # tx
2022-10-24 00:48:52,278 # rx
2022-10-24 00:48:52,279 # stop
2022-10-24 00:48:52,280 # rx
2022-10-24 00:48:53,132 # stop
2022-10-24 00:48:53,136 # [cc26x2_cc13x2_rf]: reading packet of length 36
2022-10-24 00:48:53,137 # RSSI: -29
2022-10-24 00:48:53,137 # rx
2022-10-24 00:48:53,138 # stop
2022-10-24 00:48:53,138 # write
2022-10-24 00:48:53,139 # tx
2022-10-24 00:48:53,146 # rx
2022-10-24 00:48:53,148 # stop
2022-10-24 00:48:53,148 # tx
2022-10-24 00:48:53,156 # rx
2022-10-24 00:48:53,157 # stop
2022-10-24 00:48:53,158 # tx
2022-10-24 00:48:53,162 # [cc26x2_cc13x2_rf]: failed to transmit
2022-10-24 00:48:53,167 # [cc26x2_cc13x2_rf]: reading packet of length 36
2022-10-24 00:48:53,171 # [cc26x2_cc13x2_rf]: buffer is too small

The problem is that once this "buffer is too small" message comes out, the network device (Netdev) stops working.

@SpooniSpoon
Copy link

@kYc0o
Thanks setting the correct serial number of the debug probe fixed the flash issue.

CW-75
CW-75 reviewed Oct 25, 2022
View reviewed changes
cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c
Comment on lines +315 to +318
if ((res = cc26x2_cc13x2_rf_request_transmit()) != 0) {
DEBUG("[cc26x2_cc13x2_rf]: failed to transmit\n");
RFC_DBELL_NONBUF->RFCPEIFG = ~CPE_IRQ_LAST_COMMAND_DONE;
}
Copy link
Contributor

@CW-75 CW-75 Oct 25, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying keep in a loop the transmit process until the Radio cpu returns a CPE_IRQ_LAST_COMMAND_DONE interruption. This would keep alive the network interface during TX/RX operations.

Suggested change
if ((res = cc26x2_cc13x2_rf_request_transmit()) != 0) {
DEBUG("[cc26x2_cc13x2_rf]: failed to transmit\n");
RFC_DBELL_NONBUF->RFCPEIFG = ~CPE_IRQ_LAST_COMMAND_DONE;
}
while ((res = cc26x2_cc13x2_rf_request_transmit()) != 0) {
DEBUG("[cc26x2_cc13x2_rf]: failed to transmit\n");
RFC_DBELL_NONBUF->RFCPEIFG = ~CPE_IRQ_LAST_COMMAND_DONE;
RFC_DBELL_NONBUF->RFCPEIEN |= CPE_IRQ_LAST_COMMAND_DONE;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's probably a bug on my side as an error should be returned there, the ieee80215 upper layers should handle failed transmissions if any, maybe a goto end; would be more appropriate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unrelated to the buffer to small issue though, would be great to check on cc26x2_cc13x2_rf_request_transmit what is failing.

Copy link
Contributor

@CW-75 CW-75 Oct 26, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, you are right, this refers to the "failed to transmit" issue, here it's repeating the process to trasmit until obtain a response from the radio CPU. Respecting to the upper layer i saw an issue generated after this error is printed.
Error Generated after "failed to transmit"

2022-10-26 15:02:03,412 # gnrc_netif: can't queue packet for sending
2022-10-26 15:02:03,415 # gnrc_netif: can't queue packet for sending
2022-10-26 15:02:04,412 # gnrc_netif: can't queue packet for sending

So, maybe could be presented in sys/net/gnrc/netif/gnrc_netif.c between the lines 1844 and 1862

jeandudey
jeandudey reviewed Oct 26, 2022
View reviewed changes
cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c
Comment on lines +250 to +254
if (max_size < pktlen) {
DEBUG("[cc26x2_cc13x2_rf]: buffer is too small\n");
entry->status = RFC_DATA_ENTRY_PENDING;
return -ENOBUFS;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eduazocar if you could try again here and print before the if the max_size, pktlen and buf it would help a lot. It's strange that the caller is passing a buffer too small than the received packet.

(unless a larger than expected frame was received)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the receive process this is returned:

2022-10-27 00:19:14,691 # [cc26x2_cc13x2_rf]: reading packet of length 43
2022-10-27 00:19:14,692 # Packet length: 43
2022-10-27 00:19:14,694 # Max size: 43
2022-10-27 00:19:14,710 # Buffer: 0x0 0x0 0x0 0x0 0xE8 0x17 0x0 0x0 0x2D 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xD8 0x17 0x0 0x0 0x8 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0xFE 0x58 0xB8 0x13 0x0 0x0 0x0 0x0 0x0 0x0

CW-75
CW-75 reviewed Oct 28, 2022
View reviewed changes
cpu/cc26xx_cc13xx/include/cc26xx_cc13xx_rfc_queue.h
Comment on lines +86 to +99
/**
* @brief Data entry general
*/
typedef struct {
uint8_t* next_entry; /**< Pointer to next entry in the queue */
uint8_t status; /**< Indicates status of entry, including whether it is free
for the system CPU to write to */
rfc_data_entry_config_t config; /**< Data entry configuration */
uint16_t length; /**< For pointer entries: Number of bytes in the data buffer
pointed to. For other entries: Number of bytes
following this length field */
uint8_t data; /**< First byte of the data array to be received or
transmitted */
} rfc_data_entry_general_t;
Copy link
Contributor

@CW-75 CW-75 Oct 28, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @kYc0o, I have a question about radio_general_data_entry_t structures.
I have been comparing with the datasheet, and the last data element referred to in the code is taking a uint8_t value, my question is the following, according to what is specified in table 25-11 of the datasheet, the data member should not be a type pointer void? (I mean void because it is a content of any type and its size is unknown)
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an uint8_t* pointer because the data it points to is a buffer which happens to contain that structure/header at the start, a void* works too but it's semantics IMO.

Copy link
Contributor Author

@kYc0o kYc0o Nov 2, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well maybe the void* would solve the casting problem? This warnings were activated on the latest release so I really don't know what was the brackground. E.g.:

/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c: In function 'cc26x2_cc13x2_rfc_isr':
/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c:124:28: warning: cast increases required alignment of target type [-Wcast-align]
  124 |         uint16_t pktlen = *(uint16_t *)&entry->data;
      |                            ^
/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c: In function '_read':
/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c:239:15: warning: cast increases required alignment of target type [-Wcast-align]
  239 |     pktlen = *(uint16_t *)&entry->data;
      |               ^
/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c: In function '_len':
/Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio/cc26x2_cc13x2_rf_radio_ops.c:277:24: warning: cast increases required alignment of target type [-Wcast-align]
  277 |     uint16_t pktlen = *(uint16_t *)&entry->data;
      |                        ^

@krzysztof-cabaj
Copy link
Contributor

krzysztof-cabaj commented Nov 2, 2022 •
edited
Loading

Hi @kYc0o!

I flash this PR to the cc1352R1 and after reset there are no output and I cannot access shell. If you have debug version of this code I could try run it and send you output.

Update.

I set ENABLE_DEBUG in cpu/cc26x2_cc13x2/rfc/cc26x2_cc13x2_rfc.c to 1.

After this change and board reset I receive only two logs (few attempts made, always this same result):

2022-11-02 17:49:20,459 # [cc26x2_cc13x2_rfc]: boot done, RFCPEIFG=20000000
2022-11-02 17:49:20,463 # [cc26x2_cc13x2_rfc]: changing HF osc to XOSC

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 3, 2022

Hi @kYc0o!

I flash this PR to the cc1352R1 and after reset there are no output and I cannot access shell. If you have debug version of this code I could try run it and send you output.

Update.

I set ENABLE_DEBUG in cpu/cc26x2_cc13x2/rfc/cc26x2_cc13x2_rfc.c to 1.

After this change and board reset I receive only two logs (few attempts made, always this same result):

2022-11-02 17:49:20,459 # [cc26x2_cc13x2_rfc]: boot done, RFCPEIFG=20000000
2022-11-02 17:49:20,463 # [cc26x2_cc13x2_rfc]: changing HF osc to XOSC

Could you share the application you try to run on the board?
On my case, it works just fine while flashing gnrc_networking as follows:

% BOARD=cc1352-launchpad WERROR=0 make -C examples/gnrc_networking flash term
make: Entering directory '/Users/facosta/git/RIOT-OS/RIOT/examples/gnrc_networking'
Building application "gnrc_networking" for "cc1352-launchpad" with MCU "cc26x2_cc13x2".

"make" -C /Users/facosta/git/RIOT-OS/RIOT/boards/cc1352-launchpad
"make" -C /Users/facosta/git/RIOT-OS/RIOT/boards/common/init
"make" -C /Users/facosta/git/RIOT-OS/RIOT/core
"make" -C /Users/facosta/git/RIOT-OS/RIOT/core/lib
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/periph
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/radio
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26x2_cc13x2/rfc
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26xx_cc13xx
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cc26xx_cc13xx/periph
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cortexm_common
"make" -C /Users/facosta/git/RIOT-OS/RIOT/cpu/cortexm_common/periph
"make" -C /Users/facosta/git/RIOT-OS/RIOT/drivers
"make" -C /Users/facosta/git/RIOT-OS/RIOT/drivers/netdev
"make" -C /Users/facosta/git/RIOT-OS/RIOT/drivers/netdev_ieee802154_submac
"make" -C /Users/facosta/git/RIOT-OS/RIOT/drivers/periph_common
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/auto_init
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/div
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/event
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/evtimer
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/fmt
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/frac
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/isrpipe
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/libc
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/luid
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/malloc_thread_safe
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/crosslayer/inet_csum
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netapi
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netif
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netif/hdr
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netif/ieee802154
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netif/init_devs
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netif/pktq
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/netreg
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/icmpv6
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/icmpv6/echo
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/icmpv6/error
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/ipv6
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/ipv6/hdr
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/ipv6/nib
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/ndp
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/ctx
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag/fb
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag/rb
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/iphc
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/network_layer/sixlowpan/nd
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/pkt
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/pktbuf
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/pktbuf_static
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/pktdump
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/routing/rpl
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/gnrc/transport_layer/udp
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/link_layer/eui_provider
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/link_layer/ieee802154
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/link_layer/l2util
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/netif
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/netutils
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/network_layer/icmpv6
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/network_layer/ipv6/addr
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/network_layer/ipv6/hdr
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/network_layer/sixlowpan
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/net/transport_layer/udp
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/newlib_syscalls_default
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/od
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/ps
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/random
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/shell
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/shell/cmds
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/stdio_uart
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/trickle
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/tsrb
"make" -C /Users/facosta/git/RIOT-OS/RIOT/sys/ztimer
   text	   data	    bss	    dec	    hex	filename
  90528	    540	  29632	 120700	  1d77c	/Users/facosta/git/RIOT-OS/RIOT/examples/gnrc_networking/bin/cc1352-launchpad/gnrc_networking.elf
/Applications/ti/uniflash_8.0.0//dslite.sh --config /Users/facosta/git/RIOT-OS/RIOT/boards/common/cc26xx_cc13xx/dist/cc1352r1_XDS110.ccxml /Users/facosta/git/RIOT-OS/RIOT/examples/gnrc_networking/bin/cc1352-launchpad/gnrc_networking.elf
Executing the following command:
> /Applications/ti/uniflash_8.0.0/deskdb/content/TICloudAgent/osx/ccs_base/DebugServer/bin/DSLite flash --config /Users/facosta/git/RIOT-OS/RIOT/boards/common/cc26xx_cc13xx/dist/cc1352r1_XDS110.ccxml /Users/facosta/git/RIOT-OS/RIOT/examples/gnrc_networking/bin/cc1352-launchpad/gnrc_networking.elf

For more details and examples, please refer to the UniFlash Quick Start guide.

Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
Cortex_M4_0: GEL Output: Memory Map Initialization Complete.
Cortex_M4_0: GEL Output: Board Reset Complete.
/Users/facosta/git/RIOT-OS/RIOT/dist/tools/pyterm/pyterm -p "/dev/tty.usbmodemL41008PN1" -b "115200"  
Twisted not available, please install it if you want to use pyterm's JSON capabilities
2022-11-03 09:56:53,559 # Connect to serial port /dev/tty.usbmodemL41008PN1
/Users/facosta/git/RIOT-OS/RIOT/dist/tools/pyterm/pyterm:289: DeprecationWarning: setDaemon() is deprecated, set the daemon attribute instead
  receiver_thread.setDaemon(1)
Welcome to pyterm!
Type '/exit' to exit.
2022-11-03 09:56:57,776 # NETOPT_TX_END_IRQ not implemented by driver
2022-11-03 09:56:57,785 # main(): This is RIOT! (Version: 2022.10-devel-1151-g8a0be-pr/add_cc26x2_cc13x2_radio)
2022-11-03 09:56:57,789 # RIOT network stack example application
2022-11-03 09:56:57,791 # All up, running the shell now
>

To see the shell output I just reset the device by hand, using the reset button on the board.

@krzysztof-cabaj
Copy link
Contributor

I use this same program examples/gnrc_networking. Output below. Maybe the problem is with my old toolchain - generated in my environment code is larger than yours for around 4500 bytes.

/data/RIOT-kYc0o/RIOT/examples/gnrc_networking$ make BOARD=cc1352-launchpad WERROR=0 
Building application "gnrc_networking" for "cc1352-launchpad" with MCU "cc26x2_cc13x2".

"make" -C /data/RIOT-kYc0o/RIOT/boards/cc1352-launchpad
"make" -C /data/RIOT-kYc0o/RIOT/boards/common/init
"make" -C /data/RIOT-kYc0o/RIOT/core
"make" -C /data/RIOT-kYc0o/RIOT/core/lib
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26x2_cc13x2
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26x2_cc13x2/periph
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26x2_cc13x2/radio
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26x2_cc13x2/rfc
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26xx_cc13xx
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cc26xx_cc13xx/periph
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cortexm_common
"make" -C /data/RIOT-kYc0o/RIOT/cpu/cortexm_common/periph
"make" -C /data/RIOT-kYc0o/RIOT/drivers
"make" -C /data/RIOT-kYc0o/RIOT/drivers/netdev
"make" -C /data/RIOT-kYc0o/RIOT/drivers/netdev_ieee802154_submac
"make" -C /data/RIOT-kYc0o/RIOT/drivers/periph_common
"make" -C /data/RIOT-kYc0o/RIOT/sys
"make" -C /data/RIOT-kYc0o/RIOT/sys/auto_init
"make" -C /data/RIOT-kYc0o/RIOT/sys/div
"make" -C /data/RIOT-kYc0o/RIOT/sys/event
"make" -C /data/RIOT-kYc0o/RIOT/sys/evtimer
"make" -C /data/RIOT-kYc0o/RIOT/sys/fmt
"make" -C /data/RIOT-kYc0o/RIOT/sys/frac
"make" -C /data/RIOT-kYc0o/RIOT/sys/isrpipe
"make" -C /data/RIOT-kYc0o/RIOT/sys/libc
"make" -C /data/RIOT-kYc0o/RIOT/sys/luid
"make" -C /data/RIOT-kYc0o/RIOT/sys/malloc_thread_safe
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/crosslayer/inet_csum
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netapi
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netif
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netif/hdr
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netif/ieee802154
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netif/init_devs
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netif/pktq
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/netreg
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/icmpv6
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/icmpv6/echo
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/icmpv6/error
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/ipv6
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/ipv6/hdr
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/ipv6/nib
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/ndp
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/ctx
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag/fb
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/frag/rb
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/iphc
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/network_layer/sixlowpan/nd
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/pkt
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/pktbuf
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/pktbuf_static
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/pktdump
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/routing/rpl
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/gnrc/transport_layer/udp
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/link_layer/eui_provider
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/link_layer/ieee802154
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/link_layer/l2util
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/netif
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/netutils
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/network_layer/icmpv6
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/network_layer/ipv6/addr
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/network_layer/ipv6/hdr
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/network_layer/sixlowpan
"make" -C /data/RIOT-kYc0o/RIOT/sys/net/transport_layer/udp
"make" -C /data/RIOT-kYc0o/RIOT/sys/newlib_syscalls_default
"make" -C /data/RIOT-kYc0o/RIOT/sys/od
"make" -C /data/RIOT-kYc0o/RIOT/sys/ps
"make" -C /data/RIOT-kYc0o/RIOT/sys/random
"make" -C /data/RIOT-kYc0o/RIOT/sys/shell
"make" -C /data/RIOT-kYc0o/RIOT/sys/shell/cmds
"make" -C /data/RIOT-kYc0o/RIOT/sys/stdio_uart
"make" -C /data/RIOT-kYc0o/RIOT/sys/trickle
"make" -C /data/RIOT-kYc0o/RIOT/sys/tsrb
"make" -C /data/RIOT-kYc0o/RIOT/sys/ztimer
   text	   data	    bss	    dec	    hex	filename
  95228	    548	  29312	 125088	  1e8a0	/data/RIOT-kYc0o/RIOT/examples/gnrc_networking/bin/cc1352-launchpad/gnrc_networking.elf

@kYc0o
Copy link
Contributor Author

kYc0o commented Nov 4, 2022

@krzysztof-cabaj if you have docker you may try to build it using it, just set BUILD_IN_DOCKER=1 on your make instruction. Flash and term should just work with your native toolchain.

@krzysztof-cabaj
Copy link
Contributor

Thanks for good idea. I have to install docker in machine used for RIOT development and test this issue once again.

@luisan00
Copy link
Contributor

Hi @kYc0o!

I flash this PR to the cc1352R1 and after reset there are no output and I cannot access shell. If you have debug version of this code I could try run it and send you output.

Update.

I set ENABLE_DEBUG in cpu/cc26x2_cc13x2/rfc/cc26x2_cc13x2_rfc.c to 1.

After this change and board reset I receive only two logs (few attempts made, always this same result):

2022-11-02 17:49:20,459 # [cc26x2_cc13x2_rfc]: boot done, RFCPEIFG=20000000
2022-11-02 17:49:20,463 # [cc26x2_cc13x2_rfc]: changing HF osc to XOSC

Try updating the CCFG as follows:

  • Open Uniflash, select and start with your board, go to Settings & Utilities and under Manual Erase make sure the option Erase entire flash (You must reconnect to the target afterwards is active, then push the button Erase entire flash
    Captura desde 2022-11-18 13-27-00

  • As described in cpu/cc26xx_cc13xx: add & link CCFG configuration  #14219 compile the shown example by @kYc0o in the pr description but adding the cflag or select the config option "Update CCFG":

Using CFLAGS

CFLAGS="-DCONFIG_CC26XX_CC13XX_UPDATE_CCFG=1" BOARD=cc1312-launchpad WERROR=0 make -C examples/gnrc_networking flash term

(Or) Using menuconfig

BOARD=cc1312-launchpad WERROR=0 make -C examples/gnrc_networking menuconfig flash term

Captura desde 2022-11-18 13-27-48

and save changes of course, not perfect yet but should enable terminal

@saeidakbari
Copy link

Would you have any comments on this? Do you know if it is still in the progress of development?

@kYc0o
Copy link
Contributor Author

kYc0o commented Apr 18, 2023

Would you have any comments on this? Do you know if it is still in the progress of development?

So far it may be waiting for #19198 and #19052

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@CW-75 CW-75 CW-75 left review comments

@jeandudey jeandudey jeandudey left review comments

@smlng smlng Awaiting requested review from smlng

@leandrolanzieri leandrolanzieri Awaiting requested review from leandrolanzieri leandrolanzieri is a code owner

@aabadie aabadie Awaiting requested review from aabadie aabadie is a code owner

@MichelRottleuthner MichelRottleuthner Awaiting requested review from MichelRottleuthner MichelRottleuthner is a code owner

@fjmolinas fjmolinas Awaiting requested review from fjmolinas

@miri64 miri64 Awaiting requested review from miri64 miri64 is a code owner

@haukepetersen haukepetersen Awaiting requested review from haukepetersen

@PeterKietzmann PeterKietzmann Awaiting requested review from PeterKietzmann PeterKietzmann is a code owner

@cgundogan cgundogan Awaiting requested review from cgundogan

@jia200x jia200x Awaiting requested review from jia200x

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
Area: boards Area: Board ports Area: cpu Area: CPU/MCU ports Area: drivers Area: Device drivers Area: network Area: Networking Area: sys Area: System Area: tests Area: tests and testing framework Platform: ARM Platform: This PR/issue effects ARM-based platforms
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@kYc0o @SpooniSpoon @jeandudey @CW-75 @krzysztof-cabaj @luisan00 @saeidakbari