Re: Troubles with CAN bus on STM32 Nucleo-F446RE
Hi, I contributed the board level CAN driver support for Nucleo F446RE board few months ago and I did some tests of receiving and transmitting CAN messages with a low cost WCMCU-230 transceiver (https://www.aliexpress.com/item/ 32686393467.html). It was working fine, actually if you configure and compile ./tools/configure.sh nucleo-f446re:can and run an example application "can", it should send 100 messages over CAN1 (RX PB_8 pin, TX PB _9 pin) unless there were some recent major changes to STM32 CAN driver. If I remember correctly, I noticed some problems when the application was in read and write mode instead of just single read or single write mode. I am not sure whether it was the same problem you describe as it was some time ago. I also did small tests with pysimCoder using maxon motor CAN block and it was also transmitting messages without any obvious problems. I haven´t tried receiving thought. I hope this helps. Best regards, Michal Lenc -- Původní e-mail -- Od: Roberto Bucher Komu: dev@nuttx.apache.org Datum: 7. 7. 2021 17:23:35 Předmět: Troubles with CAN bus on STM32 Nucleo-F446RE "Hi I'm trying to send messages using the CAN bus on the nucleo-f446re. The RX and TX of the STM32 is connected to a MIKROE transceiver (the same working without problems with the nucleo-STM32F746ZG board, but the bus stop after 8 messages (I think that stops because of the full output buffer...) Does somebody reaches to communicate with CAN bus using this board? Thanks in advance BR Roberto "
Re: LPC1769 Progmem
> The pagesize should be the same as the erase block size.. 4k.
If it is so (which makes sense, regardless of what the comments say), then
what is the purpose of up_progmem_erasesize ?
It should return the same thing I guess?
The function up_progmem_erasesize was what made me think that pagesize is a
different thing.
---
Regarding the MTD comments.
Thank you very much for your advice.
Fortunately my driver handles all of these cases quite well.
It accesses the Flash memory directly, and ensures all needed wear-leveling
and error checking
(at least to the extent that it is necessary in this specific application).
I just need a working progmem interface, to provide it with.
STM32 works correctly for me till now; LPC is the one that needs fixing.
Στις Πέμ, 8 Ιουλ 2021 στις 5:28 μ.μ., ο/η Gregory Nutt
έγραψε:
> The pagesize should be the same as the erase block size.. 4k.
>
> You will probably want 512b sectors (pages, or whatever we call them
> now) at the file system interface. You can also read-modify-write
> operations to "simulate" smaller erase blocks. Most MTD drivers do
> that. In that case they report the simulated erase block size. The
> overhead is an internal, large 4Kb buffer.
>
> You can also use drivers/mtd/sector512.c to get a "generic"
> read-modify-write implementation and 512 b "simulated" erase blocks like:
>
> FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
> FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);
>
>
> On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:
> > Still looking at this driver, and how to improve it.
> >
> > The LPC1769 needs data to be written in 256 bytes chunks, but Flash
> sectors
> > are erased in 4k or 32k sizes.
> >
> > So, a couple of questions:
> >
> > 1. What should up_progmem_pagesize return , 256 or 4k/32k?
> > By the description I suppose it should be 256.
> > This is not true however for the STM32 arch.
> >
> > 2. What should up_progmem_getpage return?
> > I guess 256 again...?
> >
> > But how up_progmem_eraseblock is expected to work?
> > There is no up_progmem_getblock, so there is no way that the application
> > knows which block to pass.
> > In STM32 I used up_progmem_getpage, but by checking the functions
> > descriptions now, I guess this shouldn't be correct?
> >
> > Or should "page" here refer to the 4k/32k sectors?
> >
> >
> >
> > Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
> > f.j.pa...@gmail.com> έγραψε:
> >
> >> Oh, that's great. That should definitely make the interface better.
> >>
> >> But nevertheless, I tried to "ignore" the terms, and still I can't make
> >> any sense of it.
> >>
> >> This is what I try to do (which works fine on an STM32F4):
> >>
> >> int write_data(intptr_t addr, BootData_t * data){
> >> if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
> >> return 0;
> >>
> >> if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
> >> return -EIO;
> >>
> >> return up_progmem_write(addr, data, sizeof(BootData_t));}
> >>
> >>
> >> I see that up_progmem_getpage() makes an unreasonable calculation.
> >> It calculates the "page" as if it is 256 bytes, while in fact LPC1769
> has
> >> 4k and 32k sectors...
> >>
> >>
> >>
> >> Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
> >> xiaoxiang781...@gmail.com> έγραψε:
> >>
> >>> Here has some discussion about the naming:
> >>> https://github.com/apache/incubator-nuttx/pull/3834
> >>>
> >>> On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos <
> f.j.pa...@gmail.com
> >>> wrote:
> >>>
> Hello,
>
> I am porting an old application to NuttX.
> This is running on a hardware board that uses the NXP LPC1769 MCU.
> I am in need of the up_progmem interface.
>
> Unfortunately, I see that this driver is broken. It is not working,
> >>> always
> returning an error.
> I checked its internals, but it is quite a mess. It makes wrong
> calculations on the sector sizes, it confuses the terms "page" and
> >>> "sector"
> etc.
> I see that it makes some calculations on the addresses, that to my
> knowledge do not reflect the hardware in any way.
>
> Is it actually that broken, or am I using it so incorrectly?
> Has anyone used it before successfully?
>
> I would appreciate a MWE of this driver. Or someone to confirm that it
> >>> is
> not working before I start to rewrite it.
>
>
>
Re: LPC1769 Progmem
Hello
Note that in "real" field-deployed product this sector512 layer should
NOT be used since it will wear the flash much faster than using a real
MTD filesystem.
One thing to keep in mind is that flash takes a significant time to
erase and write, and that if interrupted, a flash memory zone can be
half-erased or half-written, because in the end, we are talking about
injecting a bunch of electrons in a floating silicon gate.
In that case data will have the potential to become unstable, since
sometimes the number of electrons will be just at the limit where the
sense amplifiers distinguish a one or a zero, leading to transient flash
errors.
A real flash file system SHALL use error detection via CRCs and
redundancy. it is not correct to assume that a flash will be stable like
a hard disk in a real product that can sustain power interruptions.
The use of FAT filesystems is noticeably horrifying in this context.
Notice that here I am talking about all kind of flashes, not just NAND.
NOR flash (spi-based and internal to MCUs) can also have these partial
states.
At least, a resilient product should have a large storage cap on its
VCC/flash vcc and use a GPIO interrupt to detect the power interruption
(many switching converters have a PWROK output), so the flash can at
least finish its current operation. In case of power failure, flash
writes after the current operation to finish shall be forbidden. A
built-in brown-out detector may not be sufficient, since it only
guarantees operation of the CPU core, not ability to write flash.
Sebastien
Le 08/07/2021 à 16:28, Gregory Nutt a écrit :
The pagesize should be the same as the erase block size.. 4k.
You will probably want 512b sectors (pages, or whatever we call them
now) at the file system interface. You can also read-modify-write
operations to "simulate" smaller erase blocks. Most MTD drivers do
that. In that case they report the simulated erase block size. The
overhead is an internal, large 4Kb buffer.
You can also use drivers/mtd/sector512.c to get a "generic"
read-modify-write implementation and 512 b "simulated" erase blocks like:
FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);
On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:
Still looking at this driver, and how to improve it.
The LPC1769 needs data to be written in 256 bytes chunks, but Flash
sectors
are erased in 4k or 32k sizes.
So, a couple of questions:
1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.
2. What should up_progmem_getpage return?
I guess 256 again...?
But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?
Or should "page" here refer to the 4k/32k sectors?
Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
Oh, that's great. That should definitely make the interface better.
But nevertheless, I tried to "ignore" the terms, and still I can't make
any sense of it.
This is what I try to do (which works fine on an STM32F4):
int write_data(intptr_t addr, BootData_t * data){
if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
return 0;
if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
return -EIO;
return up_progmem_write(addr, data, sizeof(BootData_t));}
I see that up_progmem_getpage() makes an unreasonable calculation.
It calculates the "page" as if it is 256 bytes, while in fact
LPC1769 has
4k and 32k sectors...
Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
xiaoxiang781...@gmail.com> έγραψε:
Here has some discussion about the naming:
https://github.com/apache/incubator-nuttx/pull/3834
On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos
wrote:
Hello,
I am porting an old application to NuttX.
This is running on a hardware board that uses the NXP LPC1769 MCU.
I am in need of the up_progmem interface.
Unfortunately, I see that this driver is broken. It is not working,
always
returning an error.
I checked its internals, but it is quite a mess. It makes wrong
calculations on the sector sizes, it confuses the terms "page" and
"sector"
etc.
I see that it makes some calculations on the addresses, that to my
knowledge do not reflect the hardware in any way.
Is it actually that broken, or am I using it so incorrectly?
Has anyone used it before successfully?
I would appreciate a MWE of this driver. Or someone to confirm
that it
is
not working before I start to rewrite it.
Re: LPC1769 Progmem
The pagesize should be the same as the erase block size.. 4k.
You will probably want 512b sectors (pages, or whatever we call them
now) at the file system interface. You can also read-modify-write
operations to "simulate" smaller erase blocks. Most MTD drivers do
that. In that case they report the simulated erase block size. The
overhead is an internal, large 4Kb buffer.
You can also use drivers/mtd/sector512.c to get a "generic"
read-modify-write implementation and 512 b "simulated" erase blocks like:
FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);
On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:
Still looking at this driver, and how to improve it.
The LPC1769 needs data to be written in 256 bytes chunks, but Flash sectors
are erased in 4k or 32k sizes.
So, a couple of questions:
1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.
2. What should up_progmem_getpage return?
I guess 256 again...?
But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?
Or should "page" here refer to the 4k/32k sectors?
Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
Oh, that's great. That should definitely make the interface better.
But nevertheless, I tried to "ignore" the terms, and still I can't make
any sense of it.
This is what I try to do (which works fine on an STM32F4):
int write_data(intptr_t addr, BootData_t * data){
if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
return 0;
if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
return -EIO;
return up_progmem_write(addr, data, sizeof(BootData_t));}
I see that up_progmem_getpage() makes an unreasonable calculation.
It calculates the "page" as if it is 256 bytes, while in fact LPC1769 has
4k and 32k sectors...
Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
xiaoxiang781...@gmail.com> έγραψε:
Here has some discussion about the naming:
https://github.com/apache/incubator-nuttx/pull/3834
On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos
Hello,
I am porting an old application to NuttX.
This is running on a hardware board that uses the NXP LPC1769 MCU.
I am in need of the up_progmem interface.
Unfortunately, I see that this driver is broken. It is not working,
always
returning an error.
I checked its internals, but it is quite a mess. It makes wrong
calculations on the sector sizes, it confuses the terms "page" and
"sector"
etc.
I see that it makes some calculations on the addresses, that to my
knowledge do not reflect the hardware in any way.
Is it actually that broken, or am I using it so incorrectly?
Has anyone used it before successfully?
I would appreciate a MWE of this driver. Or someone to confirm that it
is
not working before I start to rewrite it.
Re: LPC1769 Progmem
Still looking at this driver, and how to improve it.
The LPC1769 needs data to be written in 256 bytes chunks, but Flash sectors
are erased in 4k or 32k sizes.
So, a couple of questions:
1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.
2. What should up_progmem_getpage return?
I guess 256 again...?
But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?
Or should "page" here refer to the 4k/32k sectors?
Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
> Oh, that's great. That should definitely make the interface better.
>
> But nevertheless, I tried to "ignore" the terms, and still I can't make
> any sense of it.
>
> This is what I try to do (which works fine on an STM32F4):
>
> int write_data(intptr_t addr, BootData_t * data){
> if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
> return 0;
>
> if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
> return -EIO;
>
> return up_progmem_write(addr, data, sizeof(BootData_t));}
>
>
> I see that up_progmem_getpage() makes an unreasonable calculation.
> It calculates the "page" as if it is 256 bytes, while in fact LPC1769 has
> 4k and 32k sectors...
>
>
>
> Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
> xiaoxiang781...@gmail.com> έγραψε:
>
>> Here has some discussion about the naming:
>> https://github.com/apache/incubator-nuttx/pull/3834
>>
>> On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos > >
>> wrote:
>>
>> > Hello,
>> >
>> > I am porting an old application to NuttX.
>> > This is running on a hardware board that uses the NXP LPC1769 MCU.
>> > I am in need of the up_progmem interface.
>> >
>> > Unfortunately, I see that this driver is broken. It is not working,
>> always
>> > returning an error.
>> > I checked its internals, but it is quite a mess. It makes wrong
>> > calculations on the sector sizes, it confuses the terms "page" and
>> "sector"
>> > etc.
>> > I see that it makes some calculations on the addresses, that to my
>> > knowledge do not reflect the hardware in any way.
>> >
>> > Is it actually that broken, or am I using it so incorrectly?
>> > Has anyone used it before successfully?
>> >
>> > I would appreciate a MWE of this driver. Or someone to confirm that it
>> is
>> > not working before I start to rewrite it.
>> >
>>
>
