May I ask the moderator about the FSMC issue?

gundan

May I ask the moderator about the FSMC issue? [Copy link]

When will the FSMC multi-master access conflict bug of the STM32F103xCDE series be solved? Is ST still preparing to solve this problem? Through understanding the market positioning of STM32, it seems that ST is not very eager to solve this bug. After all, few people use it. But if it is solved, won’t the application scope of STM32 be wider?

I have been using STM32 series products. Among similar products, STM32 has many advantages, especially the features of FSMC.
However, this FSMC does have such a big bug, which makes people feel like they are disappointed.

Recently, I am working on a project. When the OS is installed, external RAM must be used. At the same time, the device needs DMA support, but the internal 64kRAM is not enough for the device. Due to this bug of stm32, the device selection of the project has not been finalized. If it doesn’t work, I can only use arm9.

staraa

Is this question complicated?

Will the FSMC multi-master access conflict bug be resolved in future versions?
If so, how many versions will it be? How long will it take for the new version to be released?

I don't understand why you are avoiding answering this question.

amdvsxp

It's not "avoiding the answer", it's that there is no answer.

I will definitely change it, but I don't have a timetable.

kkhtkkht

Oh, it's painful, STM32 is good in everything, but this bug makes me very depressed.
It seems that I can only use software to circumvent it first, and then upgrade the chip after changing it.


I am mainly worried that the correction of this bug is not in ST's plan. After all, DMA and FSMC are available separately, and other manufacturers' similar Cotex-M3 products do not have FSMC, so this bug has a relatively small impact on ST's marketing.

zsmbj

                                 Trying new technology often means being a guinea pig, haha

postman

I chose STM32 because it has better functions than similar products. For example, 12-bit ADC, DAC and high-speed GPIO are my favorites.

Why doesn't NXP come to its senses? They have been waving 10-bit ADC for many years. They have released several generations of products, but they are still 10-bit. Now 10-bit ADCs are everywhere and have no competitiveness at all. The reason I gave up NXP in the beginning was that its GPIO speed was not as fast as 51. Although the architecture was improved later, it didn't work well. In this case, I have to be a guinea pig.

hsd325

                                 Yes! I feel like ST doesn't care much about this bug.

kenli

                                 I hate this BUG so much that I changed many of my previous design methods!

skdarkness

                                 To be honest, if LZ wants to use OS, it is best to use ARM9. Generally, OS requires MMU, but STM32 does not have MMU and is not suitable for applications using operating systems. If you like the cost-effectiveness of Cortex-M3, it is also recommended to use a CPU frequency greater than 100MHz.

comnet001

Reply to the moderator, it is RTOS, does not use MMU, has a small kernel, but the application has a large demand for data memory.
ST's Cortex-M3 series has a maximum frequency of only 72MHz, but it is enough. Cortex-M3 has excellent performance, equivalent to 100M ARM7. Other companies' products cannot meet the requirements in terms of peripherals, such as ADC is only 10 bits, and the speed is not fast enough, DAC units are too few or even non-existent, etc. Otherwise, only external ADC or DAC is needed, but the cost is a problem (the price of ADC with a sampling rate of 12 bits or more and 1M can buy an STM32), and the most important thing is that there is no FSMC, the RAM capacity cannot be expanded, and it cannot meet the requirements of large data volumes.
Overall, STM32 is the best choice. Of course, if the FSMC bug is fixed, this product will be almost perfect.

It is not impossible to use ARM9, but it will waste performance, and the cost is high (SDRAM has little cost performance in small and medium capacity), and the production scrap rate is relatively high (ARM9 is generally BGA packaged, the production technology in this village is relatively backward, and BGA is very prone to welding failure). For me, it is a choice when there is really no other choice.

I post this message just to hope that ST can pay enough attention to this bug and fix it as soon as possible, which will be good news for many developers.

zhaoheping

Thank you for your support.

According to my experience, to fix this bug, you need to make major changes, which takes a lot of time and the results are hard to predict.

For your application, I suggest two ways to bypass this bug: 1) use internal RAM as DMA buffer, 2) when DMA transfers data to external RAM, limit the program to access only internal RAM, or execute WFI, WFE instructions to wait for DMA to complete.

Of course, if you can retransmit data when DMA transfer fails, and recover through software when encountering this bug and entering an error exception, you can work more efficiently.

yanxd1983

The problem of multi-master access has been solved.

In addition, STM32 already has models with built-in 768K and 1024K Flash, and the built-in RAM has also been expanded to 96K bytes.

a7016

Is the conflict between the maximum AD sampling rate of STM32 and the USB clock a bug?
Has ST never considered fixing this useless issue ?

kgood

Is the conflict between the maximum AD sampling rate of STM32 and the USB clock a bug?
Has ST never considered fixing this useless issue ?

It depends on how you understand and define the word "BUG". As far as I understand it, this is not a BUG.

031005

Oh, it's nothing. It seems that ST has the same view on this issue as you do. Just bear with it. Haha

yoyomomo

                                 It is indeed a bit difficult to change the hardware, it is better to start from the software, but it would be better if ST could provide a solution.