Re: STM32H7: What happened with the CANFD driver?
Hi guys, I worked on this driver and opened the PR you both are referring too. I have been slammed with other things at work, which have prevented me from diving back into this. I will say that I have been actively using this driver in it's current state on NuttX 8.2 with no problems. I initially published it as a draft because I wanted others to get eyes on it and maybe play around with it some more (knowing my time to work on it was ending) and poke holes in it's functionality. In reality, it could probably be merged without issue since the core functionality is there and working. Most of the issues I mentioned in the PR are related to secondary features (RTR, bit rate switching, etc) that have not been tested yet. The one thing that should probably be changed before merging this in is the issue of a single RCC reset line. In it's current state, resetting the peripheral resets both CAN controllers, which really is no good. I outlined one possible alternative approach for fixing this in the PR. The other thing I was unsure of is whether the dedicated message RAM for the device is cacheable:/ / /"I am uncertain about whether the message RAM is cacheable. The memory mapped address falls within the peripheral device space, which as far as I can tell is uncacheable. I could be wrong about this, but the driver currently seems to work as expected without any cache coherency operations in play"/ If anyone has any insight on this, I would appreciate it. At this point, I'm fairly certain that space is not cacheable since I haven't run into any issues. I'm prepared to be told I am dead wrong though! I don't currently have the time or means to get this tested on NuttX master unfortunately. I /might/ be able to swing a little time here and there to help out a little if someone wants to collaborate. I'm sorry to have left it in this state! :/ - John On 7/22/21 12:18 PM, Nathan Hartman wrote: On Thu, Jul 22, 2021 at 4:55 AM Frank-Christian Kruegel wrote: Hi! Some months ago a member of this mailing list submitted a CANFD driver for STM32H7. What happened with this driver? Is it stuck in the review process? Is additional work to do? Best regards Frank-Christian Hello, Are you referring to PR-2987? [1] It is still marked as a "Draft" PR and therefore cannot be merged. I didn't study it in depth but there seems to be a list of unfinished work listed there (in the PR description). Probably the best way to move it forward is to try to contact the PR author and perhaps collaborate on finishing any outstanding issues to get this ready for review/merge. [1] https://github.com/apache/incubator-nuttx/pull/2987 Cheers Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: CANFD on ST32H7
pr is up https://github.com/apache/incubator-nuttx/pull/2987 - John On 3/4/21 4:54 PM, Nathan Hartman wrote: On Thu, Mar 4, 2021 at 3:49 PM John Rippetoe wrote: The fact that I have not done this yet has been haunting me for months. I think I sorted out the issues in the meantime and am trying to find time to at least rebase my changes on master and get a draft PR up for people to get eyes on. Sorry for the delay. No need to be sorry! This is a volunteer effort and the community appreciates improvements, whenever they come. :-) Whenever you get a chance, do feel free to put up a PR. Even if not 100% complete, you can mark the PR as a Draft to prevent it being merged, but start getting review/feedback on it immediately. Cheers, Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 ethernet hardfaults
Wow, that was fast David! Good find on the cache invalidation issue. I'll get your fix running on my board to verify the hard faults have been resolved. Thanks everyone for all of your input and help! - John On 3/5/21 9:11 AM, David Sidrane wrote: PR is in. Please have a look and test with the default CONFIG_NET_ETH_PKTSIZE. All should be happy now. :) https://github.com/apache/incubator-nuttx/pull/2985 -Original Message- From: David Sidrane [mailto:david.sidr...@nscdg.com] Sent: Friday, March 05, 2021 1:26 AM To: 'dev@nuttx.apache.org' Subject: RE: STM32H7 ethernet hardfaults Hi, Thank you all for sharing your Networking and dcache expertise! The descriptors and buffers are all aligned and sized for the dcache line size. The problem is the following. (The value of number do not matter, but help express the nature of the problem.) If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network is received by the F7. The DMA HW will store the frame as n buffer sizes segments and one or 0 remainder sizes buffer. The following will happen: 490 becomes 608 after the sizing and alignment. DMA populates the buffers from the descriptors +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in RDES0[29:16]) - 4 || |V |D1->B1(608) || | V | D2->B2(298) | | | | V <+Dn->Bn[] From RM410: To compute the amount of valid data in this final buffer, the driver must read the frame length (FL bits in RDES0[29:16]) and subtract the sum of the buffer sizes of the preceding buffers in this frame. But the code is invalidating from &B0[0] to &B0[1513]. If the buffers were contiguous in memory this would be ok. But the buffers that are used in RX are replaced (in the descriptors) from the free pool using the g_txbuffer memory. While at boot B0 to Bn are contiguous, they become scattered as a process of receiving (the nature of the ring and replacement from the free pool) The ring: /* Scan descriptors owned by the CPU. Scan until: * * 1) We find a descriptor still owned by the DMA, * 2) We have examined all of the RX descriptors, or * 3) All of the TX descriptors are in flight. * The replacement: buffer = stm32_allocbuffer(priv); /* Take the buffer from the RX descriptor of the first free * segment, put it into the network device structure, then * replace the buffer in the RX descriptor with the newly * allocated buffer. */ dev->d_buf= (uint8_t *)rxcurr->rdes2; rxcurr->rdes2 = (uint32_t)buffer; Eventually, B0 is allocated from one of the buffers in the g_txbuffer array. Given this layout of memory low-high /* Descriptor allocations */ g_rxtable[RXTABLE_SIZE] g_txtable[TXTABLE_SIZE] /* Buffer allocations */ g_rxbuffer[RXBUFFER_ALLOC] g_txbuffer[TXBUFFER_ALLOC] /* These are the pre-allocated Ethernet device structures */ stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET]; The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length 1514 NOT the buffer length! The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is dev->d_buf and + dev->d_len are both 0. Context before the call to up_invalidate_dcache dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)] dev->d_len = 1514 up_invalidate_dcache((uintptr_t)dev->d_buf, (uintptr_t)dev->d_buf + dev->d_len); Context after the call to up_invalidate_dcache dev->d_buf =0 dev->d_len = 0 This then returns OK and stm32_receive dereferences a null pointer and places the null into the free pool. The hard fault then happens. When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen because sizeof FRAME == sizeof BUFFER (The system will still crash if the hardware can receive a bigger frame the numbers are relaitve) The driver is not quite right, the code manages the segments but does not coalesce them back in to a frame. (memcpy with such a DMA is gross thought) So the data RX data is useless to the network layer. If the network layers used IOB and could deal with on the fly assembly the system would be most efficient. But that is a major undertaking. The goal now is to harden the driver. 1) Discard frames (all segments) grater then the size of one buffer. 2) Fix the invalidation. David -Original Message- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Thursday, March 04, 2021 5:01 PM To: dev@nuttx.apache.org Subject: Re: STM32H7 ethernet hardfaults My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE has to be 1514? So that ultimately a frame must be received completely into one buffer? Search for packet and frame in the Ethernet section of the reference manual. The hardware will DMA up
Re: STM32H7 ethernet hardfaults
Alan, The MAC in the the H7 has it's own dedicated internal DMA, so I don't think that disabling the system-wide DMA would have any effect. I can give it a shot anyways though and report back! Thanks for the suggestion. - John On 3/4/21 4:00 PM, Alan Carvalho de Assis wrote: Hi John, Did you try to disable DMA support to see if the issue disappear? I think other MCUs are using DMA for Ethernet too and this issue didn't happen. So I think disabling DMA could be a valid test to find out the root causes. BR, Alan On 3/4/21, John Rippetoe wrote: Hello All, I've been playing around with networking on the STM32H7 and am seeing hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log below, the driver would appear to be dropping packets that are too large to fit into the default packet size of 590. By increasing the packet size to the max (1518), the problem seems to disappear, but I am a little confused why the driver is able to catch the fact that the received packet was too large and drop it appropriately, but then crash. After poking around the ethernet driver, I think I understand the issue to be that because the MAC DMA does not know that the buffer it is writing into has a size limit, it is overflowing the buffer and writing into adjacent memory. Am I understanding this correctly? My main concern here is that increasing NET_ETH_PKTSIZE to the limit will only hide the issue for a time instead of solving it. A quick google search does show that the maximum ethernet frame size is 1518 bytes though, so I am working under the assumption that maxing it out in my config will account for all possible frame sizes and eliminate this issue. I have no experience with low level networking protocols and standards, so I thought it would be prudent to seek out additional help to make sure I am on the right track. Thanks in advance. - John stm32_receive: WARNING: DROPPED Too big: 684 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1332 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1264 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 684 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1364 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1264 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1436 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1300 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! up_hardfault: PANIC!!! Hard fault: 4000 up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 task: lpwork up_registerdump: R0: 24012080 2401206e 024e 24012000 40029160 24011fc0 8040 up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 0001 38002f88 080a26a7 080a2538 up_registerdump: xPSR: 8100 BASEPRI: 00f0 CONTROL: up_registerdump: EXC_RETURN: ffe9 up_dumpstate: sp: 24010bb0 up_
Re: CANFD on ST32H7
The fact that I have not done this yet has been haunting me for months. I think I sorted out the issues in the meantime and am trying to find time to at least rebase my changes on master and get a draft PR up for people to get eyes on. Sorry for the delay. - John On 12/29/20 4:37 PM, John Rippetoe wrote: Those are both good ideas; thanks for the pointer. My driver is currently based on NuttX 8.2, so I need to rebase and clean some stuff up, but once I do that I will get a PR started. - John On 12/28/20 11:05 AM, Nathan Hartman wrote: On Mon, Dec 28, 2020 at 10:40 AM John Rippetoe wrote: I have actually implemented the FDCAN driver for the H7, but have yet to submit a pull request because of a lingering bug I haven't had the time to sort out. I could clean up my code and push it to personal repo if you wanted to play around with it. Maybe put a REVISIT comment that describes the bug, place it in the code as near to where you believe the bug is as possible, and go ahead and submit a PR and mark it as a draft. Perhaps as part of the review process the cause of the bug will be discovered. As an additional possibility, require EXPERIMENTAL to build the code until the bug is solved. Cheers, Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
STM32H7 ethernet hardfaults
Hello All, I've been playing around with networking on the STM32H7 and am seeing hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log below, the driver would appear to be dropping packets that are too large to fit into the default packet size of 590. By increasing the packet size to the max (1518), the problem seems to disappear, but I am a little confused why the driver is able to catch the fact that the received packet was too large and drop it appropriately, but then crash. After poking around the ethernet driver, I think I understand the issue to be that because the MAC DMA does not know that the buffer it is writing into has a size limit, it is overflowing the buffer and writing into adjacent memory. Am I understanding this correctly? My main concern here is that increasing NET_ETH_PKTSIZE to the limit will only hide the issue for a time instead of solving it. A quick google search does show that the maximum ethernet frame size is 1518 bytes though, so I am working under the assumption that maxing it out in my config will account for all possible frame sizes and eliminate this issue. I have no experience with low level networking protocols and standards, so I thought it would be prudent to seek out additional help to make sure I am on the right track. Thanks in advance. - John stm32_receive: WARNING: DROPPED Too big: 684 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1332 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1264 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 684 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1364 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1264 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1436 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! stm32_receive: WARNING: DROPPED Too big: 1300 ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! ipv4_input: WARNING: Not destined for us; not forwardable... Dropping! up_hardfault: PANIC!!! Hard fault: 4000 up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 task: lpwork up_registerdump: R0: 24012080 2401206e 024e 24012000 40029160 24011fc0 8040 up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 0001 38002f88 080a26a7 080a2538 up_registerdump: xPSR: 8100 BASEPRI: 00f0 CONTROL: up_registerdump: EXC_RETURN: ffe9 up_dumpstate: sp: 24010bb0 up_dumpstate: IRQ stack: up_dumpstate: base: 24010c00 up_dumpstate: size: 0200 up_dumpstate: used: 0140 up_stackdump: 24010ba0: 24010bb0 2400e830 064c 080a0fed 00f0 240120b8 0001 up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 080a129f 080a1271 080f754f up_stackdump: 24010be0: 00f0 080a2935 00f0 38002eb4 40029160 24011fc0 8040 080a1b8f up_dumpstate: sp: 38002f88 up_dumpstate: User stack: up_dumpstate: base: 38003008 up_dumpstate: size: 064c up_dumpstate: used: 03e0 up_stackdum
Re: CANFD on ST32H7
Those are both good ideas; thanks for the pointer. My driver is currently based on NuttX 8.2, so I need to rebase and clean some stuff up, but once I do that I will get a PR started. - John On 12/28/20 11:05 AM, Nathan Hartman wrote: On Mon, Dec 28, 2020 at 10:40 AM John Rippetoe wrote: I have actually implemented the FDCAN driver for the H7, but have yet to submit a pull request because of a lingering bug I haven't had the time to sort out. I could clean up my code and push it to personal repo if you wanted to play around with it. Maybe put a REVISIT comment that describes the bug, place it in the code as near to where you believe the bug is as possible, and go ahead and submit a PR and mark it as a draft. Perhaps as part of the review process the cause of the bug will be discovered. As an additional possibility, require EXPERIMENTAL to build the code until the bug is solved. Cheers, Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: CANFD on ST32H7
Hi Frank, I have actually implemented the FDCAN driver for the H7, but have yet to submit a pull request because of a lingering bug I haven't had the time to sort out. I could clean up my code and push it to personal repo if you wanted to play around with it. - John Rippetoe On 12/17/20 11:06 AM, Frank-Christian Kruegel wrote: Hi, I'm currently in the process of testing all peripherials on my Nucleo STM32H743ZI board. So far, I2C, SPI, UART, and Ethernet seem to work. My next step would be CANFD, but I've noticed that there is no stm32_can.c/.h in arch/arm/src/stm32h7 as there is for stm32f7. Since the F7 doen't have CANFD I assume I cannot use the f7 can driver on the h7 even if I would loose CAN-FD capability. Are there plans to support CAN on STM32H7? Is there any schedule for this? Thanks Frank-Christian CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Thread-aware debugging for STM32H7 with OpenOCD
It turns out I had already modified the offsets in nuttx_header when I took a quick stab at this a few months back. I guess it has been so long that I forgot. Thank you very much for pointing me in the right direction on this Alan. I will definitely be giving your new gdb script a try Masayuki. Thank you for all of your work on NuttX debugging! - John On 8/27/20 8:16 PM, Masayuki Ishikawa wrote: Hi Alan and all, Alan's comment is right. Because openocd-nuttx needs to know about tcb_s members in NuttX to access them. and both values must be the same. Otherwise, openocd-nuttx does not work correctly. However, this procedure is sometimes annoying (even for me) if we are debugging multiple targets having different configurations. So, I implemented .nuttx-gdbinit which is a gdb script and it does not rely on openocd-nuttx. Actually, we can do thread-aware debugging for the NuttX simulator on x86_64 for which we can not use openocd. Of course, we can do thread-aware debugging for the NuttX for Cortex-M boards with **normal** openocd as well. The script is still experimental and not merged into the NuttX upstream and it has to be used with gdb supporting python. For Arm environment, we have to use arm-none-eabi-gdb-py instead of arm-none-eabi-gdb. Actually I'm using the following gdb to debug Cortex-M boards. $ arm-none-eabi-gdb-py --version GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git So if you are interested in the script. Please try the following git. $ git clone -b gdbinit_for_nuttx https://github.com/masayuki2009/incubator-nuttx On Fri, Aug 28, 2020 at 6:59 AM Alan Carvalho de Assis wrote: Hi John, If the tcb_s values returned are the same from openocd header, then you don't need to do anything. If they are different you need to update, otherwise it will not work reliably. BR, Alan On 8/27/20, John Rippetoe wrote: Alan, Thanks for sending this! Gustavo's suggestion of adding the '-rtos nuttx' flag to my config did the trick, so maybe this process isn't needed anymore? - John On 8/27/20 5:29 PM, Alan Carvalho de Assis wrote: Hi John, On 8/27/20, John Rippetoe wrote: Hi everyone, I recently jumped back into working on the FDCAN driver for the STM32H7 and have something working which I would like to test further. In doing so, I was hoping to easily debug with GDB through OpenOCD, but am having some issues with the necessary setup. So far I have compiled and tested the upstream master of OpenOCD, master of the Sony OpenOCD fork, and a third build that merged the latest upstream OpenOCD commits into the Sony fork. With all three, I am only ever able to see the currently running thread (nearly always IDLE) when running the "info threads" command. So my question is, does anyone have any experience getting this working? I looked through the mailing list and saw a few messages regarding this very thing for different architectures. I've also dug around on the internet to help me piece together what needed to be done to get this working. I initially got the impression that as long as OpenOCD supports your chip, thread aware-debugging should be possible, but now I'm not so sure. I modified nuttx_header.h within OpenOCD with the correct offset values as noted here https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/ That didn't change anything, unfortunately. I also thought it was possible this step was no longer needed based on the Sony fork's wiki page https://github.com/sony/openocd-nuttx/wiki The monitor commands listed there gave me "invalid command name" errors when loading my nuttx binary. Any help on this would be greatly appreciated. I tested it some years ago and Masayuki gave me some important instructions: 1) You need to include "-rtos nuttx" in the target create line of the /usr/local/share/openocd/scripts/target/stm32f4x.cfg to use with stm32f4discovery board: target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap -rtos nuttx 2) Add this code to your .gdbinit define print-offset print /x &((struct tcb_s *)(0))->pid print /x &((struct tcb_s *)(0))->xcp.regs print /x &((struct tcb_s *)(0))->task_state print /x &((struct tcb_s *)(0))->name print /x sizeof(((struct tcb_s *)(0))->name) end Then start gdb with nuttx to load the symbol. $ arm-none-eabi-gdb ./nuttx Before connecting to the target, obtain the symbol offsets in tcb. (gdb) print-offset $1 = 0xc $2 = 0x80 $3 = 0x1a $4 = 0xcc $5 = 0x20 (gdb) Then you need to put those value inside the header file: openocd/src/rtos/nuttx_header.h replacing the existing value: /* default offset */ #define PID 0xc #define XCPREG 0x70 #define STATE 0x19 #define NAME 0xb8 #define NAME_SIZE 32 Compile and install again openocd with the right values. I hope it help you! BR, Alan CONFIDENTIALITY NOT
Re: Thread-aware debugging for STM32H7 with OpenOCD
Alan, Thanks for sending this! Gustavo's suggestion of adding the '-rtos nuttx' flag to my config did the trick, so maybe this process isn't needed anymore? - John On 8/27/20 5:29 PM, Alan Carvalho de Assis wrote: Hi John, On 8/27/20, John Rippetoe wrote: Hi everyone, I recently jumped back into working on the FDCAN driver for the STM32H7 and have something working which I would like to test further. In doing so, I was hoping to easily debug with GDB through OpenOCD, but am having some issues with the necessary setup. So far I have compiled and tested the upstream master of OpenOCD, master of the Sony OpenOCD fork, and a third build that merged the latest upstream OpenOCD commits into the Sony fork. With all three, I am only ever able to see the currently running thread (nearly always IDLE) when running the "info threads" command. So my question is, does anyone have any experience getting this working? I looked through the mailing list and saw a few messages regarding this very thing for different architectures. I've also dug around on the internet to help me piece together what needed to be done to get this working. I initially got the impression that as long as OpenOCD supports your chip, thread aware-debugging should be possible, but now I'm not so sure. I modified nuttx_header.h within OpenOCD with the correct offset values as noted here https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/ That didn't change anything, unfortunately. I also thought it was possible this step was no longer needed based on the Sony fork's wiki page https://github.com/sony/openocd-nuttx/wiki The monitor commands listed there gave me "invalid command name" errors when loading my nuttx binary. Any help on this would be greatly appreciated. I tested it some years ago and Masayuki gave me some important instructions: 1) You need to include "-rtos nuttx" in the target create line of the /usr/local/share/openocd/scripts/target/stm32f4x.cfg to use with stm32f4discovery board: target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap -rtos nuttx 2) Add this code to your .gdbinit define print-offset print /x &((struct tcb_s *)(0))->pid print /x &((struct tcb_s *)(0))->xcp.regs print /x &((struct tcb_s *)(0))->task_state print /x &((struct tcb_s *)(0))->name print /x sizeof(((struct tcb_s *)(0))->name) end Then start gdb with nuttx to load the symbol. $ arm-none-eabi-gdb ./nuttx Before connecting to the target, obtain the symbol offsets in tcb. (gdb) print-offset $1 = 0xc $2 = 0x80 $3 = 0x1a $4 = 0xcc $5 = 0x20 (gdb) Then you need to put those value inside the header file: openocd/src/rtos/nuttx_header.h replacing the existing value: /* default offset */ #define PID 0xc #define XCPREG 0x70 #define STATE 0x19 #define NAME 0xb8 #define NAME_SIZE 32 Compile and install again openocd with the right values. I hope it help you! BR, Alan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Thread-aware debugging for STM32H7 with OpenOCD
Gustavo, Adding that line to my config appears to have done the trick! The info for the work queue threads still appear a little garbled, but maybe that is normal? Here is the output (gdb) info threads Id Target Id Frame * 2 Thread 603982356 "" (Name: Idle Task, pid:0, RUNNING) up_idle () at common/arm_idle.c:63 3 Thread 939531824 "" (Name: init, pid:3, WAIT_SEM) 0x in ?? () 4 Thread 939525520 "" (Name: hpwork, pid:1, WAIT_SIG) 0x in ?? () 5 Thread 939528544 "" (Name: lpwork, pid:2, WAIT_SIG) 0x in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 939525520)] #0 0x in ?? () I did a quick test and was able to set breakpoints and step through the CAN example app. I could also see that thread just fine. Thank you very much for the pointer! - John On 8/27/20 5:12 PM, Gustavo Henrique Nihei wrote: Hi John, you can follow the guide from Sony's wiki page and use OpenOCD master branch from upstream repository. Then you just need to configure OpenOCD to enable thread awareness by adding the following line to you config file: "stm32h7x.cpu0 configure -rtos nuttx" Please, find attached an example OpenOCD config file for the STM32H7 single core CPU. Best regards, Gustavo. On Thu, Aug 27, 2020 at 5:47 PM John Rippetoe mailto:jrippe...@roboticresearch.com>> wrote: Hi everyone, I recently jumped back into working on the FDCAN driver for the STM32H7 and have something working which I would like to test further. In doing so, I was hoping to easily debug with GDB through OpenOCD, but am having some issues with the necessary setup. So far I have compiled and tested the upstream master of OpenOCD, master of the Sony OpenOCD fork, and a third build that merged the latest upstream OpenOCD commits into the Sony fork. With all three, I am only ever able to see the currently running thread (nearly always IDLE) when running the "info threads" command. So my question is, does anyone have any experience getting this working? I looked through the mailing list and saw a few messages regarding this very thing for different architectures. I've also dug around on the internet to help me piece together what needed to be done to get this working. I initially got the impression that as long as OpenOCD supports your chip, thread aware-debugging should be possible, but now I'm not so sure. I modified nuttx_header.h within OpenOCD with the correct offset values as noted here https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/ That didn't change anything, unfortunately. I also thought it was possible this step was no longer needed based on the Sony fork's wiki page https://github.com/sony/openocd-nuttx/wiki The monitor commands listed there gave me "invalid command name" errors when loading my nuttx binary. Any help on this would be greatly appreciated. Thanks, John CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently. -- Gustavo Henrique Nihei CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Thread-aware debugging for STM32H7 with OpenOCD
Hi everyone, I recently jumped back into working on the FDCAN driver for the STM32H7 and have something working which I would like to test further. In doing so, I was hoping to easily debug with GDB through OpenOCD, but am having some issues with the necessary setup. So far I have compiled and tested the upstream master of OpenOCD, master of the Sony OpenOCD fork, and a third build that merged the latest upstream OpenOCD commits into the Sony fork. With all three, I am only ever able to see the currently running thread (nearly always IDLE) when running the "info threads" command. So my question is, does anyone have any experience getting this working? I looked through the mailing list and saw a few messages regarding this very thing for different architectures. I've also dug around on the internet to help me piece together what needed to be done to get this working. I initially got the impression that as long as OpenOCD supports your chip, thread aware-debugging should be possible, but now I'm not so sure. I modified nuttx_header.h within OpenOCD with the correct offset values as noted here https://micro-ros.github.io/docs/tutorials/advanced/nuttx/debugging/ That didn't change anything, unfortunately. I also thought it was possible this step was no longer needed based on the Sony fork's wiki page https://github.com/sony/openocd-nuttx/wiki The monitor commands listed there gave me "invalid command name" errors when loading my nuttx binary. Any help on this would be greatly appreciated. Thanks, John CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
So it sounds like our options are 1. Contact Paul Patience and see if he is willing to donate the code he wrote to the ASF? 2. Leave the BSD license on the file as is Is there a preferred order in which these should be attempted? Meaning, does the ASF have a preferred set of procedures for dealing with situations like this where 3rd party licenses exist in the code? Thanks for your help Justin. Regrds, John On 5/1/20 8:33 PM, Justin Mclean wrote: HI, It’s not that every file that gets submitted needs to have an Apache license. It's only files developed at the ASF by people who have signed ICLAs. If it done by people who have not signed ICLA and it’s a new file, it should also have a ASF headers, but whoever accepts that PR is ensuring that there are no IP issues and takes responsibility for that. For any significant contribution it’s best to get an ICLA from the contributor. If a file has a 3rd party license header DO NOT change it! Even if it Apache licensed, the header the ASF uses is different to the ones 3rd parties use. The only case you can change a header is if the file was part of a software grant to the ASF or we have explicit permission from the copyright owner of that file (and there may be several) and it that case it best to get them to make that change for you. Other projects are not going to have all of these issues as they a) started at the ASF or b) have all committers sign ICLA or similar c) changed the license (and all contributors agreed on that) before coming to the ASF. Thanks, Justin CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
Well I feel dumb. I just realized that the MCAN from the samv7 is nearly identical to what is used in the STM32H7. That driver already has an ASF license plus some of the functionality that my driver is missing. So perhaps this won't be an issue after all. John On 5/1/20 3:37 PM, Nathan Hartman wrote: On Fri, May 1, 2020 at 3:30 PM John Rippetoe wrote: I've followed a few of the conversations on here regarding licensing and have been a confused as well. It seems like there are a few options, so I want to make sure I do things right. I'm not a mentor but it seems to me that if you can get him to sign an ICLA then that should eliminate all doubt. But let's wait to hear from a mentor. Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
We might also look to see of there is any of Paul's code in the current release. I wrote the original file. Paul, and many others, contributed changes to it. I don't recall Paul making substantial changes. Perhaps we could quantify that with 'git blame' may there is no code left by Paul in the file after all of these year? A quick survey of git blame on stm32/stm32_can.c doesn't show a ton of changes by Paul, but some of them still exist in my copy. So probably best to proceed with getting him involved. John CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
I've followed a few of the conversations on here regarding licensing and have been a confused as well. It seems like there are a few options, so I want to make sure I do things right. I'll wait for a mentor to chime in when they have a chance. I'm not ready to merge yet anyways; I just wanted to get the ball rolling now rather than stalling in a PR. Thanks for the help. John On 5/1/20 3:25 PM, Gregory Nutt wrote: I really would like to answer your questions, but I don't understand the Apache licensing position. Its seems ad hoc and arbitrary to me, at least for cases outside of the most mundane. Perhaps we can get some direction from and Apache mentor? Sorry, Greg On 5/1/2020 1:14 PM, John Rippetoe wrote: That's unfortunate. Hopefully he is still reachable at that email. What options should I present to him if I do get in touch with him? John On 5/1/20 3:02 PM, Gregory Nutt wrote: Since no new files are allowed to come into the repo without ASF licenses, I need some direction on how I should go about re-licensing two of the files for this driver. The files in question are arch/arm/src/stm32f7/stm32_can.h -- This is only copyrighted by Greg. Greg, do I have your permission to re-license this under the new ASF license? arch/arm/src/stm32f7/stm32_can.c -- In addition to Greg, this is also copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What steps do I need to take for this file? You have my permission on that file where I am the sole copyright holder. I have no idea what to do on the second. It cannot come into the repository, but I have not heard from Paul Patience in years. Greg CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
That's unfortunate. Hopefully he is still reachable at that email. What options should I present to him if I do get in touch with him? John On 5/1/20 3:02 PM, Gregory Nutt wrote: Since no new files are allowed to come into the repo without ASF licenses, I need some direction on how I should go about re-licensing two of the files for this driver. The files in question are arch/arm/src/stm32f7/stm32_can.h -- This is only copyrighted by Greg. Greg, do I have your permission to re-license this under the new ASF license? arch/arm/src/stm32f7/stm32_can.c -- In addition to Greg, this is also copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What steps do I need to take for this file? You have my permission on that file where I am the sole copyright holder. I have no idea what to do on the second. It cannot come into the repository, but I have not heard from Paul Patience in years. Greg CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 FDCAN driver
Hi All, Since no new files are allowed to come into the repo without ASF licenses, I need some direction on how I should go about re-licensing two of the files for this driver. The files in question are arch/arm/src/stm32f7/stm32_can.h -- This is only copyrighted by Greg. Greg, do I have your permission to re-license this under the new ASF license? arch/arm/src/stm32f7/stm32_can.c -- In addition to Greg, this is also copyrighted by Paul Alexander Patience from Omni Hoverboards Inc. What steps do I need to take for this file? Thanks, John On 4/23/20 4:48 PM, John Rippetoe wrote: I just realized that the reference I made to an external document in my first email didn't actually get linked too. For those interested, see below. [1] https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf - John On 4/23/20 3:54 PM, John Rippetoe wrote: Hello All, I have been working on adding support for the FDCAN peripheral in the STM32H7 and have a basic driver working. It's a bit of a hack in some places right now, but it follows the same basic structure as the F7 driver, which was used as a template to start. I should note that I have only been testing by using the CAN example program running in loopback mode since I do not currently have any external devices to test with. The FDCAN hardware in the H7 is a pretty significant departure from the F7 and earlier, so there is some additional functionality that the current upper-level CAN driver isn't really setup to support. I wanted to bring the community in on my efforts so we could discuss those things and decide whether they are worth pursuing. I personally have zero prior experience with CAN, so I am not sure what hardware features are typically utilized by most developers here. The biggest difference that sets the H7 FDCAN apart from its predecessors is the storage of messages. Unlike previous hardware that made use of a fixed number of mailboxes for sending/receiving messages, the H7 FDCAN integrates a 10kb segment of memory called the Message RAM that is dedicated to the peripheral. All messages, both transmitted and received, and filters are stored here. But more interestingly, the RAM is dynamically configured by the user during the initialization process based on their needs and can be split up into a variety of sections. I don't want to get into a lot of detail here since I am likely telling people what they already know, so interested parties should look at [1] for a great summary of what the hardware can do. What I would like to discuss right now is what features we want to use and some implementation ideas for them. Since the upper-level driver places messages into FIFOs, it is easy to make use of the Rx and Tx FIFOs in hardware. The filters will also be necessary for the driver to function. Right now, I have created kconfig options for configuring the sections in RAM. That allows to user to specify what sections they want, how many messages they want to store in each section, and how big the messages are expected to be. So what works right now? In short, the driver currently replicates the functionality of the F7 driver. Here is a bullet list * Hardware initialization * Bit timing * Message RAM setup for filters and FIFOs, configurable via kconfig * Rx/Tx FIFOs with appropriate interrupts * IOCTL calls implemented by F7 driver (no add/del filters) * Txready/Txdone functions * Functions to send/receive messages within hardware * Tx/Rx interrupt enable/disable What work needs to be done? * Settle on what features to implement and a way to represent the message RAM layout for efficient use by the driver * Add support for RTR messages * Add support for FD mode * Add config option to enable/disable FIFO overwrite (default setup is to block when full) * Add support for bitrate switching? * LOTS of testing * nxstyle checks * licensing since two files are derived from the F7 code that has non-ASF licenses. For now, I think the best path forward is to match the feature set of existing CAN drivers. That will allow us to get the basics working and well tested before moving onto anything that might require us to modify the upper-level driver to add more advanced features such as bitrate switching. So that means only using the hardware FIFOs for now. I think we should allow the user to configure the message RAM via kconfig options for maximum flexibility in the future. Even if we only add options for the filter and FIFO sections right now, adding in additional features later would be much easier with the infrastructure in place. It also lets the user specify exactly what they want, removing the need for the driver to hardcode potentially stupid assumptions. For filtering, I have currently enabled a single bitmask filter to accept all incoming messages. Implementing
Re: STM32H7 FDCAN driver
I just realized that the reference I made to an external document in my first email didn't actually get linked too. For those interested, see below. [1] https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf - John On 4/23/20 3:54 PM, John Rippetoe wrote: Hello All, I have been working on adding support for the FDCAN peripheral in the STM32H7 and have a basic driver working. It's a bit of a hack in some places right now, but it follows the same basic structure as the F7 driver, which was used as a template to start. I should note that I have only been testing by using the CAN example program running in loopback mode since I do not currently have any external devices to test with. The FDCAN hardware in the H7 is a pretty significant departure from the F7 and earlier, so there is some additional functionality that the current upper-level CAN driver isn't really setup to support. I wanted to bring the community in on my efforts so we could discuss those things and decide whether they are worth pursuing. I personally have zero prior experience with CAN, so I am not sure what hardware features are typically utilized by most developers here. The biggest difference that sets the H7 FDCAN apart from its predecessors is the storage of messages. Unlike previous hardware that made use of a fixed number of mailboxes for sending/receiving messages, the H7 FDCAN integrates a 10kb segment of memory called the Message RAM that is dedicated to the peripheral. All messages, both transmitted and received, and filters are stored here. But more interestingly, the RAM is dynamically configured by the user during the initialization process based on their needs and can be split up into a variety of sections. I don't want to get into a lot of detail here since I am likely telling people what they already know, so interested parties should look at [1] for a great summary of what the hardware can do. What I would like to discuss right now is what features we want to use and some implementation ideas for them. Since the upper-level driver places messages into FIFOs, it is easy to make use of the Rx and Tx FIFOs in hardware. The filters will also be necessary for the driver to function. Right now, I have created kconfig options for configuring the sections in RAM. That allows to user to specify what sections they want, how many messages they want to store in each section, and how big the messages are expected to be. So what works right now? In short, the driver currently replicates the functionality of the F7 driver. Here is a bullet list * Hardware initialization * Bit timing * Message RAM setup for filters and FIFOs, configurable via kconfig * Rx/Tx FIFOs with appropriate interrupts * IOCTL calls implemented by F7 driver (no add/del filters) * Txready/Txdone functions * Functions to send/receive messages within hardware * Tx/Rx interrupt enable/disable What work needs to be done? * Settle on what features to implement and a way to represent the message RAM layout for efficient use by the driver * Add support for RTR messages * Add support for FD mode * Add config option to enable/disable FIFO overwrite (default setup is to block when full) * Add support for bitrate switching? * LOTS of testing * nxstyle checks * licensing since two files are derived from the F7 code that has non-ASF licenses. For now, I think the best path forward is to match the feature set of existing CAN drivers. That will allow us to get the basics working and well tested before moving onto anything that might require us to modify the upper-level driver to add more advanced features such as bitrate switching. So that means only using the hardware FIFOs for now. I think we should allow the user to configure the message RAM via kconfig options for maximum flexibility in the future. Even if we only add options for the filter and FIFO sections right now, adding in additional features later would be much easier with the infrastructure in place. It also lets the user specify exactly what they want, removing the need for the driver to hardcode potentially stupid assumptions. For filtering, I have currently enabled a single bitmask filter to accept all incoming messages. Implementing the add/del filter IOCTL calls should be trivial, but I have some concerns there as well. Please feel free to take a look at the code on my H7CAN branch <https://github.com/rippetoej/incubator-nuttx/commits/H7CAN> - I am prepared for a good old-fashioned code mocking <https://dilbert.com/search_results?terms=code+mocking>. The code follows the same structure as the F7 and earlier drivers and is well documented I think. It is also based off my work in progress port of the STM32H753XI evaluation board, so you will see a few commits sprinkled in that are specific to my
Re: STM32H7 FDCAN driver
Thanks for letting me know! I was actually following the discussion on whether to include the G4 in the stm32 folder, so I knew it was being worked on. I took a quick look at the G4 reference manual and it shows that they share identical FDCAN core releases, so the basic stuff should all be the same. The main difference appears to be in the number of CAN cores (3 in the G4 vs 2 in the H7) and the amount of message RAM (1Kb per core in the G4 vs 10Kb shared between the 2 cores in the H7). It also appears that there is no Time Triggered CAN functionality in the G4. So it seems like it should be pretty easy for us to collaborate. - John On 4/23/20 4:29 PM, Nathan Hartman wrote: On Thu, Apr 23, 2020 at 3:54 PM John Rippetoe wrote: I have been working on adding support for the FDCAN peripheral in the STM32H7 and have a basic driver working. It's a bit of a hack in some I haven't yet read your whole email. I will revisit it soon. But in the meantime I wanted to mention that I'm working on architectural support in NuttX for the STM32G474 family, which also has FDCAN. In fact, yesterday, I was working on the pinmap for several peripherals, including the FDCAN. My work is in my fork on GitHub, in https://github.com/hartmannathan/incubator-nuttx in the branch stm32g474. This being a recent addition to STM32's family line, perhaps the FDCAN peripherals share some common lineage and maybe we could split some of the work to support it. I'm not ready yet, because first need to get minimal support up and running, to initialize the sysclk and boot up NuttX on my board, but I thought it be helpful to mention. Cheers, Nathan CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
STM32H7 FDCAN driver
Hello All, I have been working on adding support for the FDCAN peripheral in the STM32H7 and have a basic driver working. It's a bit of a hack in some places right now, but it follows the same basic structure as the F7 driver, which was used as a template to start. I should note that I have only been testing by using the CAN example program running in loopback mode since I do not currently have any external devices to test with. The FDCAN hardware in the H7 is a pretty significant departure from the F7 and earlier, so there is some additional functionality that the current upper-level CAN driver isn't really setup to support. I wanted to bring the community in on my efforts so we could discuss those things and decide whether they are worth pursuing. I personally have zero prior experience with CAN, so I am not sure what hardware features are typically utilized by most developers here. The biggest difference that sets the H7 FDCAN apart from its predecessors is the storage of messages. Unlike previous hardware that made use of a fixed number of mailboxes for sending/receiving messages, the H7 FDCAN integrates a 10kb segment of memory called the Message RAM that is dedicated to the peripheral. All messages, both transmitted and received, and filters are stored here. But more interestingly, the RAM is dynamically configured by the user during the initialization process based on their needs and can be split up into a variety of sections. I don't want to get into a lot of detail here since I am likely telling people what they already know, so interested parties should look at [1] for a great summary of what the hardware can do. What I would like to discuss right now is what features we want to use and some implementation ideas for them. Since the upper-level driver places messages into FIFOs, it is easy to make use of the Rx and Tx FIFOs in hardware. The filters will also be necessary for the driver to function. Right now, I have created kconfig options for configuring the sections in RAM. That allows to user to specify what sections they want, how many messages they want to store in each section, and how big the messages are expected to be. So what works right now? In short, the driver currently replicates the functionality of the F7 driver. Here is a bullet list * Hardware initialization * Bit timing * Message RAM setup for filters and FIFOs, configurable via kconfig * Rx/Tx FIFOs with appropriate interrupts * IOCTL calls implemented by F7 driver (no add/del filters) * Txready/Txdone functions * Functions to send/receive messages within hardware * Tx/Rx interrupt enable/disable What work needs to be done? * Settle on what features to implement and a way to represent the message RAM layout for efficient use by the driver * Add support for RTR messages * Add support for FD mode * Add config option to enable/disable FIFO overwrite (default setup is to block when full) * Add support for bitrate switching? * LOTS of testing * nxstyle checks * licensing since two files are derived from the F7 code that has non-ASF licenses. For now, I think the best path forward is to match the feature set of existing CAN drivers. That will allow us to get the basics working and well tested before moving onto anything that might require us to modify the upper-level driver to add more advanced features such as bitrate switching. So that means only using the hardware FIFOs for now. I think we should allow the user to configure the message RAM via kconfig options for maximum flexibility in the future. Even if we only add options for the filter and FIFO sections right now, adding in additional features later would be much easier with the infrastructure in place. It also lets the user specify exactly what they want, removing the need for the driver to hardcode potentially stupid assumptions. For filtering, I have currently enabled a single bitmask filter to accept all incoming messages. Implementing the add/del filter IOCTL calls should be trivial, but I have some concerns there as well. Please feel free to take a look at the code on my H7CAN branch <https://github.com/rippetoej/incubator-nuttx/commits/H7CAN> - I am prepared for a good old-fashioned code mocking <https://dilbert.com/search_results?terms=code+mocking>. The code follows the same structure as the F7 and earlier drivers and is well documented I think. It is also based off my work in progress port of the STM32H753XI evaluation board, so you will see a few commits sprinkled in that are specific to my board. Regards, John Rippetoe CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: The new Apache NuttX Logo
Hi all, It would be great if there were some way for the community to see the proposed logos. Maybe put them up on Confluence if possible? Regards, John On 4/13/20 10:35 AM, Alan Carvalho de Assis wrote: Hi Xiang, Thank you for sharing it. But I think the idea is that people doesn't know which design came for each person or company. Now we are biased :) BTW, my opinion is that Option #5 is a good option. All designs are too disruptive in relation to original logo, I don't know if it is a good idea. To be honest I like most the logo in this PCB, see: https://nuttx.events It is clean and resemble the original logo, but it is more simple and modern. I think it was designed by Technolution designer. BR, Alan On 4/13/20, Xiang Xiao wrote: Let's extend the discussion to all community. Hi all, please give the designer what your opinion for the new logo. Thanks Xiang On Mon, Apr 13, 2020 at 9:08 PM David Sidrane wrote: All of these except 4 and 5 have the same feel - and need an explanation to "Get it" I do not think that is what a logo is supposed to do. Can we get more options? David *From:* Xiang Xiao [mailto:xiaoxiang781...@gmail.com] *Sent:* Monday, April 13, 2020 12:41 AM *To:* Gregory Nutt; priv...@nuttx.apache.org *Cc:* Hans; Justin Mclean; palomino...@gmail.com; 李骁; nand...@xiaomi.com *Subject:* Re: The new Apache NuttX Logo Loop all PMC member. Justin, is private@ list enough for the current discussion, or should we extend to dev@ list? Thanks Xiang On Sun, Apr 12, 2020 at 7:09 AM Justin Mclean wrote: Hi, This should really be discussed on the mailing list and the PMC decide on the new logo. Most projects that do this put it up for a community vote but that’s not the only way to go, you may also want to open submissions of new logos to more than just one person. To Justin, is there any Apache convention we need to follow? For example, is "NuttX" or "Apache" text required in this logo? There’s no convention you need to follow. INAL but some logos have Apache in them, that gives you some trademark protections, if others misuse the. Nutt is already a trademark that seem fine to me and not needed. It does however make it clear it’s an Apache project. Some logos also incorporate the Apache Feather, again this is not a requirment. Most newer logos include a “TM” mark, If you want to see the full range of logos take a look here [1] Thanks, Justin 1. https://apache.org/logos/ On Sun, Apr 12, 2020 at 12:26 AM Gregory Nutt wrote: Hello, Hans, Thanks a lot for putting this effort into the NuttX logo. All of the options look great. I think I like the simplest options 1-3 better than the options with the printed circuit board theme. I would like see something that makes the logo look more lively. I always like the Zephyr logo because it is light-hearted and free and just looks like fun: [image: Zephyr (operating system) - Wikipedia] I have no idea what the significance of the kite is. I suppose because it is light and active? I am not saying we need a kite. I think we can accomplish this your options too. Perhaps with some color? Blue and white have always been the colors of NuttX, but perhaps royal blue an gold: [image: Gold and royal blue backgrounds | Custom-Designed Graphic Patterns ...] Or maybe blue and orange" [image: Holland blue and orange tulip flower tile pattern Vector Image] But I have never been great with color selections. Greg On 4/9/2020 8:52 AM, Hans wrote: Hi Greg, Justin and all, Xiao Li (lixi...@xiaomi.com) developed some ideas for the new NuttX logo. In the attached document, she laid out her thought process and gave seven options of styles. To further the design process, she needs your feedback to proceed. To Greg, can you pick your favorite from the seven options? Do you have other comments or suggestions? To Justin, is there any Apache convention we need to follow? For example, is "NuttX" or "Apache" text required in this logo? Thanks, Hans CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 support
Hi David, Assuming the H7 is a superset of the F7. By comparing the features, as realized by IP blocks, in the F7 to the H7 one can identify the new IP blocks that have not been supported. I see. I wasn't sure if there was some sort of dedicated comparison sheet somewhere that I was missing. > I'd be glad to get started on that. It seems like an appropriate starting point is to copy the appropriate files over from the F7 folder and then edit from there correct? Yes but for structure only. The H7's FDCAN IP block is much different than the F7's bxCAN IP block Definitely. I'll get started on setting up the basic stuff and start pushing to a branch on my fork. - John -Original Message- From: John Rippetoe [mailto:jrippe...@roboticresearch.com <mailto:jrippe...@roboticresearch.com>] Sent: Thursday, April 02, 2020 3:32 PM To: dev@nuttx.apache.org <mailto:dev@nuttx.apache.org> Subject: Re: STM32H7 support >> Is there a working document or set of notes detailing ongoing/needed > work for STM32H7 support? > > Not really - a diff to the F7 file usually will show the holes but there is > also the datasheet diff view. What do you mean by datasheet diff? > We used SDMMC2 in all H7 designs and that choice gave us the ability to > bring out the full ARM trace pins, so the MDMA was not high on our list. > > I will be upstreaming DMA support for the SPI driver once we complete > testing (Friday). I found a nasty along the way and will document it in the > PR. That sounds interesting, I look forward to reading what you found! > My next stop was going to be the stm32H7 CANFD driver, so if you want to > start on that it would be a great contribution and we can work on it > together. I'd be glad to get started on that. It seems like an appropriate starting point is to copy the appropriate files over from the F7 folder and then edit from there correct? - John > > Regards, > > David > > -Original Message- > From: John Rippetoe [mailto:jrippe...@roboticresearch.com <mailto:jrippe...@roboticresearch.com>] > Sent: Thursday, April 02, 2020 12:56 PM > To: dev@nuttx.apache.org <mailto:dev@nuttx.apache.org> > Subject: STM32H7 support > > Hi all, > > Is there a working document or set of notes detailing ongoing/needed > work for STM32H7 support? I've looked through the code in > arc/arm/*/stm32h7, release notes, board README, and commits/issues/PRs > on github to piece together some of what has been worked on. It appears > that a lot of the difficult groundwork has already been laid. So that I > don't duplicate any work, is anyone working on the following? > > > - MDMA support. This is especially important for SDMMC1, which doesn't > have access to SRAM1234 needed by the IDMA (see PR684 > <https://github.com/apache/incubator-nuttx/pull/684>). This seems like a > big job for a newbie like me, but there is no better way to learn than > to just dive in right? > > - Support for silicon revision-specific differences. There is some code > for this in the chip ADC driver (ADC_DEVICE_VERSION_V). I have a few > ideas for this. > > > What other things need attention? > > Thanks as always. I am looking forward to working with you all! > > - John Rippetoe > > > CONFIDENTIALITY NOTICE: This communication may contain private, confidential > and privileged material for the sole use of the intended recipient. If you > are not the intended recipient, please delete this e-mail and any > attachments permanently. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 support
Is there a working document or set of notes detailing ongoing/needed work for STM32H7 support? Not really - a diff to the F7 file usually will show the holes but there is also the datasheet diff view. What do you mean by datasheet diff? We used SDMMC2 in all H7 designs and that choice gave us the ability to bring out the full ARM trace pins, so the MDMA was not high on our list. I will be upstreaming DMA support for the SPI driver once we complete testing (Friday). I found a nasty along the way and will document it in the PR. That sounds interesting, I look forward to reading what you found! My next stop was going to be the stm32H7 CANFD driver, so if you want to start on that it would be a great contribution and we can work on it together. I'd be glad to get started on that. It seems like an appropriate starting point is to copy the appropriate files over from the F7 folder and then edit from there correct? - John Regards, David -Original Message- From: John Rippetoe [mailto:jrippe...@roboticresearch.com] Sent: Thursday, April 02, 2020 12:56 PM To: dev@nuttx.apache.org Subject: STM32H7 support Hi all, Is there a working document or set of notes detailing ongoing/needed work for STM32H7 support? I've looked through the code in arc/arm/*/stm32h7, release notes, board README, and commits/issues/PRs on github to piece together some of what has been worked on. It appears that a lot of the difficult groundwork has already been laid. So that I don't duplicate any work, is anyone working on the following? - MDMA support. This is especially important for SDMMC1, which doesn't have access to SRAM1234 needed by the IDMA (see PR684 <https://github.com/apache/incubator-nuttx/pull/684>). This seems like a big job for a newbie like me, but there is no better way to learn than to just dive in right? - Support for silicon revision-specific differences. There is some code for this in the chip ADC driver (ADC_DEVICE_VERSION_V). I have a few ideas for this. What other things need attention? Thanks as always. I am looking forward to working with you all! - John Rippetoe CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
STM32H7 support
Hi all, Is there a working document or set of notes detailing ongoing/needed work for STM32H7 support? I've looked through the code in arc/arm/*/stm32h7, release notes, board README, and commits/issues/PRs on github to piece together some of what has been worked on. It appears that a lot of the difficult groundwork has already been laid. So that I don't duplicate any work, is anyone working on the following? - MDMA support. This is especially important for SDMMC1, which doesn't have access to SRAM1234 needed by the IDMA (see PR684 <https://github.com/apache/incubator-nuttx/pull/684>). This seems like a big job for a newbie like me, but there is no better way to learn than to just dive in right? - Support for silicon revision-specific differences. There is some code for this in the chip ADC driver (ADC_DEVICE_VERSION_V). I have a few ideas for this. What other things need attention? Thanks as always. I am looking forward to working with you all! - John Rippetoe CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Build errors with inline functions
See, I was thinking that it should be treated like all other functions
with no indention of the first pair of curly brackets. I didn't look for
other multi-line macro functions to compare with though. I'll go with
whatever is consistent with existing code in the repo.
- John
On 3/25/20 4:29 PM, Gregory Nutt wrote:
I also took a look at the coding standard guide to make sure I was in
compliance, but I'm unsure of where I should put the 'do'
#define mpu_priv_stronglyordered(base, size) do \
{ \
/* The configure the region */ \
== OR ==
#define mpu_user_flash(base, size) \
do { \
/* The configure the region */ \
Tt basically should follow the same rules as other code. Still no
braces on the same line. I would have done:
#define mpu_priv_stronglyordered(base, size) \
do \
{ \
/* The configure the region */ \
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
Re: Build errors with inline functions
I moved forward with converting inline functions to macros and thought I
would share a little before moving on. Things I did
1. Per Greg's suggestion, I added #ifdef CONFIG_ARM_MPU to mpu.h and
_mpuinit.h
2. Moved static inline functions mpu_control and mpu_configure_region
to up_mpu.c. I did this for two reasons
1. mpu_configure_region was on the large side (55 lines)
2. I thought it was important to enforce type safety. mpu_control
accepts three bools that it uses for conditionals and I felt it
would be pretty easy for a user to pass any other data type and
potentially cause issues.
3. The spacing between comments would have made them ugly macros
3. Converted the remaining inline functions to macros
I validated everything was good by compiling the imxrt-106-evk:knsh and
nsh configs with
1. Protected build
2. Flat build, mpu enabled
3. Flat build, mpu disabled
I also took a look at the coding standard guide to make sure I was in
compliance, but I'm unsure of where I should put the 'do'
#define mpu_priv_stronglyordered(base, size) do \
{ \
/* The configure the region */ \
== OR ==
#define mpu_user_flash(base, size) \
do { \
/* The configure the region */ \
Thanks guys
- John
On 3/25/20 11:45 AM, Nathan Hartman wrote:
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
wrote:
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of
mpu.h and _mpuinit.h. That way, the problem is fixed in one
place for all time.
I hadn't considered that, but that does make more sense.
Another option would be to remove the inline qualifier and move the
functions into a .c file.
I'm equally fine with this, but I can see the appeal for wanting to keep
the small functions inlined. Of the 12 funcitons in mpu.h, 9 are just
wrappers around a call to mpu_configure_region that look like
static inline void mpu_priv_intsram(uintptr_t base, size_t size)
{
/* The configure the region */
mpu_configure_region(base, size,
MPU_RASR_TEX_SO | /* Ordered*/
MPU_RASR_C| /* Cacheable */
/* Not Bufferable */
MPU_RASR_S| /* Shareable */
MPU_RASR_AP_RWNO/* P:RW U:None */
/* Instruction access */);
}
Like others have said, there is no guarantee these will be inlined.
Furthermore, the build system doesn't currently enforce a minimum C99
standard to ensure the inline keyword is even available. So I am in
favor of moving the functions to a .c file in the name of clarity.
Consolidating them into up_mpu.c seems like a good choice. If the
overhead of an additional function call is problematic, we could
predefine the flags and call mpu_configure_region() directly
#define MPU_PRIV_INTSRAM MPU_RASR_TEX_SO | /* Ordered*/
MPU_RASR_C| /* Cacheable */
/* Not Bufferable */
MPU_RASR_S| /* Shareable */
MPU_RASR_AP_RWNO/* P:RW U:None */
/* Instruction access */);
mpu_configure_region(base, size, MPU_PRIV_INTSRAM);
Or change mpu_priv_intsram to macro?
That's a valid approach. Macros are C89 compliant, guaranteed to be inlined
no matter what, result in 0 code if unused, and don't cause problems in
header files.
Reminder: When implementing a function-like macro, always write it as do {
... } while (0) -- see
https://stackoverflow.com/a/257425
Cheers,
Nathan
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
Re: Build errors with inline functions
Converting them to macros certainly reduces the amount of code that
needs to change.
Thanks for the link Nathan, I will take a look at that.
John
On 3/25/20 11:45 AM, Nathan Hartman wrote:
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
wrote:
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of
mpu.h and _mpuinit.h. That way, the problem is fixed in one
place for all time.
I hadn't considered that, but that does make more sense.
Another option would be to remove the inline qualifier and move the
functions into a .c file.
I'm equally fine with this, but I can see the appeal for wanting to keep
the small functions inlined. Of the 12 funcitons in mpu.h, 9 are just
wrappers around a call to mpu_configure_region that look like
static inline void mpu_priv_intsram(uintptr_t base, size_t size)
{
/* The configure the region */
mpu_configure_region(base, size,
MPU_RASR_TEX_SO | /* Ordered*/
MPU_RASR_C| /* Cacheable */
/* Not Bufferable */
MPU_RASR_S| /* Shareable */
MPU_RASR_AP_RWNO/* P:RW U:None */
/* Instruction access */);
}
Like others have said, there is no guarantee these will be inlined.
Furthermore, the build system doesn't currently enforce a minimum C99
standard to ensure the inline keyword is even available. So I am in
favor of moving the functions to a .c file in the name of clarity.
Consolidating them into up_mpu.c seems like a good choice. If the
overhead of an additional function call is problematic, we could
predefine the flags and call mpu_configure_region() directly
#define MPU_PRIV_INTSRAM MPU_RASR_TEX_SO | /* Ordered*/
MPU_RASR_C| /* Cacheable */
/* Not Bufferable */
MPU_RASR_S| /* Shareable */
MPU_RASR_AP_RWNO/* P:RW U:None */
/* Instruction access */);
mpu_configure_region(base, size, MPU_PRIV_INTSRAM);
Or change mpu_priv_intsram to macro?
That's a valid approach. Macros are C89 compliant, guaranteed to be inlined
no matter what, result in 0 code if unused, and don't cause problems in
header files.
Reminder: When implementing a function-like macro, always write it as do {
... } while (0) -- see
https://stackoverflow.com/a/257425
Cheers,
Nathan
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
Re: Build errors with inline functions
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of
mpu.h and _mpuinit.h. That way, the problem is fixed in one
place for all time.
I hadn't considered that, but that does make more sense.
Another option would be to remove the inline qualifier and move the
functions into a .c file.
I'm equally fine with this, but I can see the appeal for wanting to keep
the small functions inlined. Of the 12 funcitons in mpu.h, 9 are just
wrappers around a call to mpu_configure_region that look like
static inline void mpu_priv_intsram(uintptr_t base, size_t size)
{
/* The configure the region */
mpu_configure_region(base, size,
MPU_RASR_TEX_SO | /* Ordered */
MPU_RASR_C | /* Cacheable */
/* Not Bufferable */
MPU_RASR_S | /* Shareable */
MPU_RASR_AP_RWNO /* P:RW U:None */
/* Instruction access */);
}
Like others have said, there is no guarantee these will be inlined.
Furthermore, the build system doesn't currently enforce a minimum C99
standard to ensure the inline keyword is even available. So I am in
favor of moving the functions to a .c file in the name of clarity.
Consolidating them into up_mpu.c seems like a good choice. If the
overhead of an additional function call is problematic, we could
predefine the flags and call mpu_configure_region() directly
#define MPU_PRIV_INTSRAM MPU_RASR_TEX_SO | /* Ordered */
MPU_RASR_C | /* Cacheable */
/* Not Bufferable */
MPU_RASR_S | /* Shareable */
MPU_RASR_AP_RWNO /* P:RW U:None */
/* Instruction access */);
mpu_configure_region(base, size, MPU_PRIV_INTSRAM);
John
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you are
not the intended recipient, please delete this e-mail and any attachments
permanently.
Re: Build errors with inline functions
Does anyone have any thoughts on this? I can start implementing the changes and set up a PR. John Rippetoe Software Engineer Robotic Research, LLC (240) 631-0008 - Original Message - From: "John Rippetoe" To: "dev" Sent: Monday, March 23, 2020 6:17:05 PM Subject: Re: Build errors with inline functions On 3/20/20 5:40 PM, David Sidrane wrote: >> the error will crop back up if MPU support is enabled without also >> performing a protected build since up_mpu.c is only included in a >> protected build. > Just a heads up there are some case on some HW (imxrt, maybe the K66 for the > DMA) were the MPU is needed to enable the proper access but not in protected > build. > I've dug through the arm portion of the repo and there appear to be a wide array of platforms affected. The solution consiss 1. For each chip, files that include mpu support need to add a conditional to two included files #ifdef CONFIG_ARM_MPU # include "mpu.h" # include "_mpuinit.h" #endif 2. Edit the Make.defs for each chip ifeq ($(CONFIG_ARM_MPU),y) CMN_CSRCS += up_mpu.c CHIP_CSRCS += stm32_mpuinit.c endif ifeq ($(CONFIG_BUILD_PROTECTED),y) CHIP_CSRCS += stm32_userspace.c endif An alternative form I found in the imxrt Make.defs (thanks for pointing me in this direction David) ifeq ($(CONFIG_ARM_MPU),y) ifneq ($(CONFIG_BUILD_PROTECTED),y) CMN_CSRCS += up_mpu.c endif CHIP_CSRCS += imxrt_mpuinit.c ifeq ($(CONFIG_BUILD_PROTECTED),y) CHIP_CSRCS += imxrt_userspace.c endif endif I personally think this is harder to read, but wanted to get other's opinions. Wrapping the _userspace.c inclusion feels unnecessary since a protected build can only be enabled when the mpu is enabled anyways. This block can also be split up so the inclusion of CMN and CHIP sources don't happen together if that is preferred. - John CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Build errors with inline functions
On 3/20/20 5:40 PM, David Sidrane wrote: the error will crop back up if MPU support is enabled without also performing a protected build since up_mpu.c is only included in a protected build. Just a heads up there are some case on some HW (imxrt, maybe the K66 for the DMA) were the MPU is needed to enable the proper access but not in protected build. I've dug through the arm portion of the repo and there appear to be a wide array of platforms affected. The solution consiss 1. For each chip, files that include mpu support need to add a conditional to two included files #ifdef CONFIG_ARM_MPU # include "mpu.h" # include "_mpuinit.h" #endif 2. Edit the Make.defs for each chip ifeq ($(CONFIG_ARM_MPU),y) CMN_CSRCS += up_mpu.c CHIP_CSRCS += stm32_mpuinit.c endif ifeq ($(CONFIG_BUILD_PROTECTED),y) CHIP_CSRCS += stm32_userspace.c endif An alternative form I found in the imxrt Make.defs (thanks for pointing me in this direction David) ifeq ($(CONFIG_ARM_MPU),y) ifneq ($(CONFIG_BUILD_PROTECTED),y) CMN_CSRCS += up_mpu.c endif CHIP_CSRCS += imxrt_mpuinit.c ifeq ($(CONFIG_BUILD_PROTECTED),y) CHIP_CSRCS += imxrt_userspace.c endif endif I personally think this is harder to read, but wanted to get other's opinions. Wrapping the _userspace.c inclusion feels unnecessary since a protected build can only be enabled when the mpu is enabled anyways. This block can also be split up so the inclusion of CMN and CHIP sources don't happen together if that is preferred. - John CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Build errors with inline functions
You can try removing the static from the inline function definitions in the header file. The code should then compile, however, you could also get multiply defined functions at link time... Or maybe the linker is smart enough to allow multiples??? Putting inline functions in header files introduces lots of problem (especially if you are using C89). If they are to be used in header files, at least they should not be declared static. Removing static didn't change anything, which makes sense given that no optimization is happening and the inline keyword is being removed by the mechanism in compiler.h Adding the always_inline attribute worked, but only when static was still attached. All of these issues go away when the standard is set as C99, so the compiler must be trimming the functions out in this scenario. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Build errors with inline functions
I think at a minimum, we need to conditionally include mpu.h only when the MPU support is actually needed. Options for that are CONFIG_ARM_MPU, CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the first two, the error will crop back up if MPU support is enabled without also performing a protected build since up_mpu.c is only included in a protected build. I know that it is possible to enable MPU support without performing a protected build, but is there any use case for this? If not, it seems odd that these would be separate options. But if there is, then we need to figure out how to get the build to compile in that scenario. That might be as simple as including up_mpu.c whenever MPU support is enabled as opposed to only doing so when a protected build is requested. Someone with more knowledge on how these two features interact would be a better source of info on that than I am. On 3/20/20 11:21 AM, Gregory Nutt wrote: If we want to support the compiler which don't support inline, it's better that: 1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h 2.Convert inline fucntion to macro to normal function It isn't hard to fix because grep just can find inline about 100 times. There are inline functions in common C files which are not a problem because we have the definitions in compiler.h. The use in header files is causing all of the problems. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Build errors with inline functions
That's interesting. Maybe there is a difference in the default flags between my compiler and what you and the build server are using. It looks like the default standard for my compiler is gnu90. I haven't done an exhaustive test on all the builds, but for starters here are a few that fail nucleo-h743i:nsh nucleo-h743i:nxlines_oled stm32h747i-disco:nsh I just found that the nucleo-h743xi:pwm config did not fail, so I dug into that and found that compiler optimizations play a role in whether the build completes. With the "No Optimization" setting selected, the build fails. Turning on "Full Optimization" allows the build to complete. I also tested all of the common custom optimzation levels -O--> works -O2 --> works -O3 --> works -O0 --> fails -Os --> works The issue crops up in flat builds because of how the build pulls in files based on the config. An example is the easiest way to show the issue. Here is one of the offending functions from the compiler error nuttx/staging/libarch.a(stm32_allocateheap.o): In function `mpu_configure_region': nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to `mpu_allocregion' mpu_allocregion is declared at line 172 of mpu.h but used within the inline function mpu_configure_region at line 278 of the same file. The function mpu_allocregion is defined at line 211 of file arch/arm/src/armv7-m/up_mpu.c, but this file is not included in the build unless CONFIG_PROTECTED_BUILD is defined (line 96 of arc/arm/src/stm32h7/Make.defs). The file mpu.h, which is the source of the errors, is non-conditionally included in stm32_allocateheap.c, which is a required file for the build. There are really two issues here (potentially) 1. mpu.h should only be included when mpu support is needed, such as with a protected build. I tested this by conditionally including mpu.h only when CONFIG_PROTECTED_BUILD is defined and that gave me a clean build. The build should be able to complete regardless of whether optimization is used or not. I suspect that adding optimization helps me in this case because the compiler recognizes that the problematic functions are not used and simply removes them, thus getting me around the error. But if I were to switch over to a protected build, I'd wager that things might break again if inlining is the issue, which leads into number 2 below. 2. The way that compiler.h currently determines inline support is incompatible with the defaults on my system, which appears to be gnu90. Given that, what is the best way for a user to specify a particular build? And since we need inline functions for this code to compile, should we not specify the minimum standard necessary in the Make.defs? Thanks for the help. Sorry this got a little long winded. - John - Original Message - From: "Abdelatif Guettouche" To: "dev" Sent: Thursday, March 19, 2020 2:29:30 PM Subject: Re: Build errors with inline functions > > The functions the compiler > is complaining about are defined in up_mpu.c, which is only included for > protected builds. So it makes sense you wouldn't see the issue when > building in protected mode. The issue should be then seen when protected mode is enabled, there where the MPU is used. libarch shouldn't contain any MPU related symbol. I built flat modes as well. All builds complete error free. You can also see in the nightly build [1], all H7 are building error free. However, the same issue occurs when trying to build the existing > H7 boards and with many of the F7 boards as well. > What boards are causing the issue? 1. https://builds.apache.org/view/Incubator%20Projects/job/NuttX-Nightly-Build/68/console On Thu, Mar 19, 2020 at 2:46 PM John Rippetoe wrote: > I'm using the generic arm-none-eabi toolchain, version 4.84. OS is > Ubuntu 16.04. The contents of my board Make.defs is below. > > > > # boards/arm/stm32h7/stm32h753xi-eval2/scripts/Make.defs > # > # Copyright (C) 2018 Gregory Nutt. All rights reserved. > # Author: Gregory Nutt > # > # Redistribution and use in source and binary forms, with or without > # modification, are permitted provided that the following conditions > # are met: > # > # 1. Redistributions of source code must retain the above copyright > #notice, this list of conditions and the following disclaimer. > # 2. Redistributions in binary form must reproduce the above copyright > #notice, this list of conditions and the following disclaimer in > #the documentation and/or other materials provided with the > #distribution. > # 3. Neither the name NuttX nor the names of its contributors may be > #used to endorse or promote products derived from this software > #without specific prior
Re: Build errors with inline functions
I'm using the generic arm-none-eabi toolchain, version 4.84. OS is Ubuntu
16.04. The contents of my board Make.defs is below.
# boards/arm/stm32h7/stm32h753xi-eval2/scripts/Make.defs
#
# Copyright (C) 2018 Gregory Nutt. All rights reserved.
# Author: Gregory Nutt
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 3. Neither the name NuttX nor the names of its contributors may be
#used to endorse or promote products derived from this software
#without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
include ${TOPDIR}/.config
include ${TOPDIR}/tools/Config.mk
include ${TOPDIR}/arch/arm/src/armv7-m/Toolchain.defs
LDSCRIPT = flash.ld
ifeq ($(WINTOOL),y)
# Windows-native toolchains
DIRLINK = $(TOPDIR)/tools/copydir.sh
DIRUNLINK = $(TOPDIR)/tools/unlink.sh
MKDEP = $(TOPDIR)/tools/mkwindeps.sh
ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
-isystem "${shell cygpath -w $(TOPDIR)/include/cxx}"
ARCHSCRIPT = -T "${shell cygpath -w
$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)}"
else
# Linux/Cygwin-native toolchain
MKDEP = $(TOPDIR)/tools/mkdeps$(HOSTEXEEXT)
ARCHINCLUDES = -I. -isystem $(TOPDIR)/include
ARCHXXINCLUDES = -I. -isystem $(TOPDIR)/include -isystem $(TOPDIR)/include/cxx
ARCHSCRIPT =
-T$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)
endif
CC = $(CROSSDEV)gcc
CXX = $(CROSSDEV)g++
CPP = $(CROSSDEV)gcc -E
LD = $(CROSSDEV)ld
AR = $(ARCROSSDEV)ar rcs
NM = $(ARCROSSDEV)nm
OBJCOPY = $(CROSSDEV)objcopy
OBJDUMP = $(CROSSDEV)objdump
ARCHCCVERSION = ${shell $(CC) -v 2>&1 | sed -n '/^gcc version/p' | sed -e
's/^gcc version \([0-9\.]\)/\1/g' -e 's/[-\ ].*//g' -e '1q'}
ARCHCCMAJOR = ${shell echo $(ARCHCCVERSION) | cut -d'.' -f1}
ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
ARCHOPTIMIZATION = -g
endif
ifneq ($(CONFIG_DEBUG_NOOPT),y)
ARCHOPTIMIZATION += $(MAXOPTIMIZATION) -fno-strict-aliasing
-fno-strength-reduce -fomit-frame-pointer
endif
ARCHCFLAGS = -fno-builtin
ARCHCXXFLAGS = -fno-builtin -fno-exceptions -fcheck-new -fno-rtti
ARCHWARNINGS = -Wall -Wstrict-prototypes -Wshadow -Wundef
ARCHWARNINGSXX = -Wall -Wshadow -Wundef
ARCHDEFINES =
ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10
CFLAGS = $(ARCHCFLAGS) $(ARCHWARNINGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS)
$(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS)
CXXFLAGS = $(ARCHCXXFLAGS) $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION)
$(ARCHCPUFLAGS) $(ARCHXXINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
CXXPICFLAGS = $(ARCHPICFLAGS) $(CXXFLAGS)
CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES)
AFLAGS = $(CFLAGS) -D__ASSEMBLY__
NXFLATLDFLAGS1 = -r -d -warn-common
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1)
-T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
LDNXFLATFLAGS = -e main -s 2048
ASMEXT = .S
OBJEXT = .o
LIBEXT = .a
EXEEXT =
ifneq ($(CROSSDEV),arm-nuttx-elf-)
LDFLAGS += -nostartfiles -nodefaultlibs
endif
ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
LDFLAGS += -g
endif
HOSTCC = gcc
HOSTINCLUDES = -I.
HOSTCFLAGS = -Wall -Wstrict-prototypes -Wshadow -Wundef -g -pipe
HOSTLDFLAGS =
John Rippetoe
Software Engineer
Robotic Research, LLC
(240) 631-0008
- Original Message -
From: "Nathan Hartman"
To: dev@nuttx.apache.org
Sent: Thursday, March 19, 2020 10:39:39 AM
Subject: Re: Build errors with inline
Re: Build errors with inline functions
I am working on a new board port for the STM32H7 that's not yet in the repo. However, the same issue occurs when trying to build the existing H7 boards and with many of the F7 boards as well. All of the affected configs are flat builds, including my own. The functions the compiler is complaining about are defined in up_mpu.c, which is only included for protected builds. So it makes sense you wouldn't see the issue when building in protected mode. To answer your other question: yes, I have done a clean build. I have also run a distclean and reconfigured, but the issue persists. The only way to get a build to complete is to comment out line 270 below from compiler.h /* GCC supports inlined functions for C++ and for C version C99 and above */ 266 # if defined(__cplusplus) || (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) 267 # define CONFIG_HAVE_INLINE 1 268 # else 269 # undef CONFIG_HAVE_INLINE 270 # define inline 271 # endif Obviously this bypasses the check for C99 support being performed here. - John On 3/19/20 7:07 AM, Abdelatif Guettouche wrote: Hi, What config are you trying to build? Did you try to run a clean build? I built a couple of the protected mode STM32 boards, they all build with no error. On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe wrote: Hello, I updated master on my repo yesterday and noticed that I can no longer build STM32H7 or F7 based boards. The compiler error in question is shown below. For what its worth, I am using standard arm-none-eabi toolchain on Ubuntu Linux. LD: nuttx nuttx/staging/libarch.a(stm32_allocateheap.o): In function `mpu_configure_region': nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to `mpu_allocregion' nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to `mpu_log2regionceil' nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to `mpu_log2regionceil' nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to `mpu_subregion' These are all functions that are declared in arch/arm/src/armv7-m/mpu.h and defined in arch/arm/src/armv7-m/up_mpu.c . They are called within various inlined functions defined in mpu.h. The issue stems from a change made by commit 3972510 <https://github.com/apache/incubator-nuttx/commit/39725109fac627ba70300c858d3c6e13187824f6>, where the logic for checking that inline functions are allowed was changed to ensure the code is being compiled with at least the C99 standard. I am still learning how the build system for NuttX is organized, so I don't know exactly where to specify which C standard to use. Should this be specified by the host system or be included as a flag in the build files for affected chips? If it is the latter, I see two possible places it could be added 1. In the chip Make.defs 2. In each board Make.defs, where the ARCHCFLAGS variable is already specified Since this affects all boards with a particular chip, it seems better to add it to the chip Make.defs. However, given that all the compiler flags are currently specified at the board level, it seems better to put it there for consistency's sake. I'm not sure how many other chips are affected by this issue yet, but it is presumably anything using inline functions. Thanks, John Rippetoe CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently. CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Build errors with inline functions
Hello, I updated master on my repo yesterday and noticed that I can no longer build STM32H7 or F7 based boards. The compiler error in question is shown below. For what its worth, I am using standard arm-none-eabi toolchain on Ubuntu Linux. LD: nuttx nuttx/staging/libarch.a(stm32_allocateheap.o): In function `mpu_configure_region': nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to `mpu_allocregion' nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to `mpu_log2regionceil' nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to `mpu_log2regionceil' nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to `mpu_subregion' These are all functions that are declared in arch/arm/src/armv7-m/mpu.h and defined in arch/arm/src/armv7-m/up_mpu.c . They are called within various inlined functions defined in mpu.h. The issue stems from a change made by commit 3972510 <https://github.com/apache/incubator-nuttx/commit/39725109fac627ba70300c858d3c6e13187824f6>, where the logic for checking that inline functions are allowed was changed to ensure the code is being compiled with at least the C99 standard. I am still learning how the build system for NuttX is organized, so I don't know exactly where to specify which C standard to use. Should this be specified by the host system or be included as a flag in the build files for affected chips? If it is the latter, I see two possible places it could be added 1. In the chip Make.defs 2. In each board Make.defs, where the ARCHCFLAGS variable is already specified Since this affects all boards with a particular chip, it seems better to add it to the chip Make.defs. However, given that all the compiler flags are currently specified at the board level, it seems better to put it there for consistency's sake. I'm not sure how many other chips are affected by this issue yet, but it is presumably anything using inline functions. Thanks, John Rippetoe CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: Rajan Gill's Project
That is some very cool work! Do all things good in the world of robotics come from ETH Zurich? It certainly seems that way. Greg, wish him best of luck for me on his defense. That is no easy task, but I have confidence he will do great. Thanks for sharing! - John On 1/22/20 3:49 AM, Alin Jerpelea wrote: Cool project Rajan, Thanks for sharing Alin On Tue, Jan 21, 2020 at 10:47 PM Gregory Nutt wrote: Rajan Gill has been a long time user of and contributer to NuttX. Today he shared a video with me that may be of interest to others: /Not sure if you remember me but this is Rajan! I am trying to finish my PhD and just wanted to share a video of one of the projects I've been working on: //https://youtu.be/ULc63HrgPro// / /Also wanted to say thanks for your help you have given me on the forums and, for of course, NuttX :)// / /I'm focused on defending my PhD now. Hopefully I'll get back to contributing to NuttX soon :D/ /Very cool to be able to see what people are up to with NuttX!/ Thank you, Rajan, Greg CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
