When compiling with all warnings enabled, some defines can lead to
warning due to missing unsigned type suffix:
warning: integer overflow in expression [-Woverflow]
This fix should not affected behavior at all, since calculation with
such overflows lead to the same actual address when writing to that
location. However, it makes the warning disappear and also defines
the right data type for a memory location.
Extension of code for STM32F1 to allow for dual bank series XL.
Small changes to documentation for F2, F4 and L1 to add a parameter reference.
Tested with STM32F103RBT6
(note: tests show that the PG bit must be cleared after programming, otherwise
a subsequent erase attempt fails. This has been added to flash_program_half_word
for F0 and F1 only. A fix for the other families is not included in this PR.)
This unifies stm32f1, l1, and f4 convenience functions for adc. The code
should be useable for f2 and f37x as well, but that needs hardware for testing,
and there was no existing implementation. This is the reason for the
"adc_common_v1.c" name, as trying to put all the different families into the
common file name has become too cumbersome.
All of the deprecated routines have been dropped, they've been marked
deprecated for a very long time now, and porting them seemed unnecessary.
This has been tested on f1, l1 and f4 discovery boards, and is based on some
existing l1/f1 unification code from
https://github.com/karlp/libopencm3/tree/rme_l1_master
This pulls out all the common header definitions for the F1, L1, F4 and F37x
parts. It's verified against the datasheet for F2 as well, but we don't have
any good F2 test boards or any support for that yet. (The F2 header would be
_exactly_ the same as the F4 header, so it's a target for a future round of
unification, not this one)
Tested with f1, f4 and l1 examples from the examples repository.
So that the navigation pane works correctly in browsers.
Some additional doc fixes put in where found (but many more still to go).
Added some dummy .c and .h files to bring the associated docs into line.
makefile changed to allow 'make html' as well as 'make doc' (the latter only does html anyway).
This converts all the YAML files to JSON files, as json parsing is built
into python instead of being a separate library requiring installation.
YAML is a superset of JSON, but putting comments in is not quite as obvious
as it is in yaml.
The following glue was used to convert yaml to json:
python -c 'import sys, yaml, json; json.dump(yaml.load(sys.stdin), sys.stdout, indent=4)' < $1 > $2
Clearly I haven't tested this on every single platform, and this
doesn't address the large blobs of yaml in the lpc4300 scripts directory,
only the cortex NVIC generation process.
I've tested a few IRQ driven example apps, and I've checked the generated
output of some known cases like the LM3s that has explicit gaps, and they are
all generated correctly.
The value '6' was twice in the table and all higher frequencies are
shifted. The values are now fitting the table in 'STM32F05xxx/06xxx advanced
ARM-based 32-bit MCUs', page 101.
PLL frequencies have been measured by selecting
rcc_set_mco(RCC_CFGR_MCO_SYSCLK);
and measuring the output with an oscilloscope. 8, 16, 24, 32, 40 and 48 MHz
work fine from the HSI base.
Add memorymap entries for ST calibration data, the vref internal, and the temp
sensor at 30C and 110C for the parts that provide this data.
F1 and F2 do not appear to have this anywhere.
According to RM0090, page 301, paragraph 11.13.12 Note. (For F4, for F1 and F3 is it in the corresponding manuals)
The JSQR are filled always ending at SQR4 ie for those lists we must set this list:
(A) -> JSQ4 = A,
(A,B) -> JSQ3 = A, JSQ4 = B,
(A,B,C) -> JSQ2 = A, JSQ3 = B, JSQ4 = C,
(A,B,C,D) -> JSQ1 = A, JSQ2 = B, JSQ3 = C, JSQ4 = D,
The readed values are in correct order, starting from JDR1:
(A) -> JDR1 = A,
(A,B) -> JDR1 = A, JDR2 = B,
(A,B,C) -> JDR1 = A, JDR2 = B, JDR3 = C,
(A,B,C,D) -> JDR1 = A, JDR2 = B, JDR3 = C, JDR4 = D,
ITM Stimulus ports need to be accessible with different sizes
The amount of data written out is determined by the size of the write.
Writing a full 32 bit value when you only need 8 for printf() style
substantially reduces the available bandwidth of the SWO
Note: this is an API change for doing 32bit writes.
Old:
ITM_STIM[stimulus_port] = value
New:
ITM_STIM32(stimulus_port) = value
This api is much more in common with some of the other registers that
behave this way. As there's very little (if any) code already using
this API, it's a good time to fix it permanently.
Remove misleading ITM register definitions
ITM_SSPSR is the supported parallel trace size, in _bits_
ITM_CSPSR is in _bits_ as well. There's really no advantage in even
having these sorts of definitions in libopencm3, as these settings are
normally controlled from the debugger side, not the target itself.
Lock and lock status register definitions were added, as per ARM:
"For ARMv7-M, the component ID registers are required for the ROM table,
and the CoreSight management lock access mechanism is defined for the
DWT, ITM, FPB and TPIU blocks."
The common code wasn't being included in L1 builds, even though the headers now
included the correct definitions.
This combines the two f0 and f3 spi files, which previously differed only in
the number of spi peripherals defined.
Files were renamed to the full "l1f124" style, not because I like it, but
because it's the convention we have, so it's best to apply it rigourously.
Tested on L1 and F100 boards, compile tested only for others, but the examples
repository all compiles too. (Though the lack of SPI examples for all
platforms was how this broke in the first place)
DFF exists at bit 11 for f1, f2, f4 and l1, but the f0 and f3 have that bit as
CRC len and use CR2 for data size bits instead. The merging of the F3 and F0
and attempts to put common data in common places broke the l1 code.
F3 and F0 SPI headers are still almost completely identical.
STM32L1 has a different set of offsets, not just a different base
address, so we can't have common registers definitions. Also, out of
F0,F1,F2,F3,F4,L1, only the F1 has the odd note about 2x16bit registers
and 2x32bit registers with one 16bit register marked as "This field
value is also reserved for a future feature." Therefore, replace the
awkward reading out as multiple words and just copy them in.
F0,F2,F3,F4 were missing definitions altogether.
This does _not_ attempt to address the problem of the mismatched base
addresses for Medium+ and High Density L1 parts.
The direct access definitions to the SHPR1 SHPR2 and SHPR3 were simply
wrong, and though a handy macro for directly reaching any priority field
was provided, the definitions of the fields assumed direct access to the
registers.
Provide field definitions that match the handy macro, and correct the
direct access definitions for people wishing to use them.
Frantisek Burian
Felix Held
Stefan Agner
Ken Sarkies
cmcmanis
Karl Palsson
memeruiz
Piotr Esden-Tempski
Onno Kortmann
Karl Palsson
Forrest Voight