How does software access "firmware" subroutines / programs?

LeafLabs Garden » Support » Maple Hardware Support

How does software access "firmware" subroutines / programs?

(16 posts) (4 voices)

Started 4 years ago by StephenFromNYC
Latest reply from mbolivar

12 Next »

StephenFromNYC
Moderator

Hello-

I am embarrassed to ask several "I never took a computer science course" type questions, but I am hoping a few quick direct answers will save me days or weeks of reading references which are not needed to answer my immediate questions (mainly about USB). The answers will determine if I need to read some of the USB code examples provided by st.com. [A side question is related to which st.com code I should read. The libmaple / usb / usb_lib / usb_regs.h file, version 2.2.1, has an internal st.com date of 9/22/2008, but I think st.com has released updated versions of this file.]

In microcontrollers such as the the STM32F103X chips used in the Maple there are simple circuits (AND, OR, XOR, etc gates) created using silicon. When combined the circuits create subroutines and programs which are related to specific functions (eg. USB). How am I doing so far?

My most basic question is how does software such as the st.com demo software and libmaple which is located in FLASH/SRAM access these hardware circuits? How does a program which exists in FLASH/SRAM access a program which which exists somewhere else on the silicon wafer?

At the lowest level (which I do *not* think I am interested in learning) I am assuming accessing these circuits requires knowing which values to put in which memory spaces and when to activate the appropriate circuits. How are circuits "activated"?

In "libmaple/usb/README" it says "when a new USB core library is written (to nix ST dependence)" which suggests that the LeafLabs crew wants their products to run without using any ST code.

Currently (March 2011) some of the USB functionality has not been duplicated yet in libmaple. For example, the functionality from the st.com code which allows isochronous USB transfers has not be duplicated in libmaple.

In becoming independent of ST code at what level does libmaple need to replicate what the ST code achieves?

To make the software/silicon connection does libmaple just need to replicate just the functionality of the ST code? In other words, for the core USB functions, is libmaple limited (or required) to using functions which match the ST code function in name only (while being given the freedom to change the body of each function). Or is libmaple free to use any function names it wants as long as the correct values are placed in the correct memory spaces (ie the functionality of the ST code)?

For example, in usb.h (found in libmaple) the following function is defined: usbReceiveBytes(uint8* recvBuf, uint32 len);

Is there a function also called usbReceiveBytes in the st.com code which has the same functionality, but different code in the function body?

When microprocessors are programmed are any variable names reserved?

I am assume there is a way for a low level function for a program to say "I am about to make several changes to different memory locations, so do not do anything until I am finished."

What is a register, and how are registers related to these questions? How are registers access (read or changed) by software?

Do you recommend any specific links or resources?

Thanks again for your time!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

Here is another, more applied, way to express what I am trying to learn.

Is there any way to write a sketch which uses the LeafLabs IDE, but with the st.com header (*.h) and source (*.c) files (in particular for full speed USB functions), which can be uploaded to a Maple board, and which runs as expected?

If I could get the interrupt/bulk/isochronous USB sample programs to run I might be able to find some time to make progress on implementing the interrupt and isochronous type USB transfers.

I appreciate why the LeafLabs teams wants to be independent of the st.com software.

Ideally, I do not want to start with a completely blank system.

It would be easier for me (or anyone else) to start with a working st.com base system and then slowly replace the st.com code with code which is easier to upgrade.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

StephenfromNYC - cracking qustions!

In microcontrollers such as the the STM32F103X chips used in the Maple there are simple circuits (AND, OR, XOR, etc gates) created using silicon.

Yes.

When combined the circuits create subroutines and programs which are related to specific functions (eg. USB). How am I doing so far?

No. The electronics of a USB peripheral, to the level of this discussion, implements the low-level behaviour directly. The circuits are organised irrevocably to implement a fixed set of functions. There is no code 'inside' the USB peripheral that we can get at.

My most basic question is how does software such as the st.com demo software and libmaple which is located in FLASH/SRAM access these hardware circuits?

The hardware is mapped into fixed memory locations (like variables at specific addresses), and specific bits within those memory locations interact with the underlying electronics.

How does a program which exists in FLASH/SRAM access a program ... which exists somewhere else on the silicon wafer?

There is only one area of programs, which is the program that is held in Flash/RAM.

At the lowest level (which I do *not* think I am interested in learning) I am assuming accessing these circuits requires knowing which values to put in which memory spaces and when to activate the appropriate circuits.

Close, and maybe this is just a typo away.
The program uses specific memory locations to put or get specific values, the electronics is 'directly connected' to specific locations and are triggered by values in those locations, and (the electronics) sets one or more bits within memory values to give back data.

How are circuits "activated"?

There is a bit of detail in the STM32F because the programmer (e.g. you) can switch power on and off for peripheral electronics, but let's skip this.
Fundamentally, memory locations are part of each peripherals electrionics, and are visible to the program.

In becoming independent of ST code at what level does libmaple need to replicate what the ST code achieves?

Yes. (If the same functionality is required,) the entire set (of ST code) needs to be implemented in code that runs from Flash/RAM.

To make the software/silicon connection does libmaple just need to replicate just the functionality of the ST code? In other words, for the core USB functions, is libmaple limited (or required) to using functions which match the ST code function in name only (while being given the freedom to change the body of each function). Or is libmaple free to use any function names it wants as long as the correct values are placed in the correct memory spaces (ie the functionality of the ST code)?

The ST code is on exactly the same footing as LeafLabs code. The LeafLabs code can use any names it likes because the names within the code will have no significance to the USB hardware.

For example, in usb.h (found in libmaple) the following function is defined: usbReceiveBytes(uint8* recvBuf, uint32 len);

Is there a function also called usbReceiveBytes in the st.com code which has the same functionality, but different code in the function body?

It is irrelevant (what the functions are called), because the names don't matter if the code is not combined into a single program and linked (which is not what you are describing).

When microprocessors are programmed are any variable names reserved?

In C programming there are names which are reserved for specific predefined purposes (e.g. main), but I am not sure that is what you mean.

I am assume there is a way for a low level function for a program to say "I am about to make several changes to different memory locations, so do not do anything until I am finished."

Yes, the only way that program flow can be diverted is by an interrupt (or exception) usually caused by a peripheral (such as a timer, or an external pin, USB, etc). There are instructions which a program can execute to control the hardware and switch off interrupts, i.e. stop the hardware diverting program flow when something happens in a peripheral.

What is a register, and how are registers related to these questions? How are registers access (read or changed) by software?

In some ways, registers are exactly the same as memory (RAM) locations. They just have very compact addresses to make encoding programs much more compact (On the STM32F, memory addresses as 32 bits, 4 bytes long, so if the instruction to add two numbers, and put the answer into a third location could only operate on memory locations, the instruction would have to contain three 4 byte locations, plus some more bits to encode the unique identity of the add instruction).
They are also available for processing in much less time than RAM, so the processor can take two register values, add them, and put the answer into a third register in less time that it takes to get one value from RAM. Registers are sometimes called the processors 'scratchpad', the program uses the registers to work things out, then writes them back to memory when the program moves on to a different task.

Do you recommend any specific links or resources?

My favourite books were:
Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book.html
but that is quite big, and abstract for the questions I think you are asking (though I may have misunderstood) (I can't see my copy, I think I loaned it to a friend (note to self), but it is about 600 pages)

My other favourite is no longer in print, but you might find a copy:
http://www.amazon.com/Introduction-Microcomputers-v-1/dp/0931988349
http://www.amazon.com/Introduction-Microcomputers-Basic-Concepts-v/dp/0079310346
This is the book that got me "into" computing. But still quite a deep dive.
It did deal in (specific and concrete) detail with how a processor worked, how it interacted with peripherals, etc.
Let me think some more. I am sure someone can think of something a bit better.
Maybe it isn't as fashionable to write books which deal with this sort of stuff as in the late 70's and early 80's.

Edit: tried to clarify my words, mostly additions are in "(...)"

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

I was hoping to get this post in before gbulmer replied, but I was too slow. I will respond to gbulmer's above post when I have time early next week.

Here is another, more applied, way to express what I am trying to learn.

Is there any way to write a sketch which uses the LeafLabs IDE, but with the st.com demo header (*.h) and source (*.c) files (in particular for full speed USB functions), which can be uploaded to a Maple board, and which runs as expected?

If I could get the interrupt/bulk/isochronous USB sample programs to run I might be able to find some time to make progress on implementing the interrupt and isochronous type USB transfers.

I appreciate why the LeafLabs teams wants to be independent of the st.com software. Ideally, I do not want to start with a completely blank system.

It may be easier for me (or anyone else) to start with a working st.com base system and then slowly replace the st.com code with code which is easier to upgrade.

Does this make sense?

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC

Is there any way to write a sketch which uses the LeafLabs IDE, but with the st.com header (*.h) and source (*.c) files (in particular for full speed USB functions), which can be uploaded to a Maple board, and which runs as expected?

Almost definitely. There is no deep 'magic'.

I've done this sort of thing with the Arduino IDE, and the same strategy will work.

Create a tab in the IDE, copy and past one of the ST code files into it , save it with the same (or similar) name as the original (let's say usb.c)
You will likely get errors because some of the header files are in the wrong place, e.g. usb.c may contain
#include <usb.h>
but in the worst case, you can fix that by putting the headers into a folder structure, and using the full path name, by code like
#include <C:/users/stephen/documents/st/include/usb.h>
into usb.c

You will get messages that functions are missing. If you have grep, you will quickly be able to find the file which contains the missing function (if you have the source). Create tabs for each file of ST code that you need.
Keep going until the compiler and linker is happy.

You will have to change the name of the main() function in the ST code. Call it something clever like mymain(), and call it from setup(). (I'd put the code for blink in loop() :-)

If I could get the interrupt/bulk/isochronous USB sample programs to run I might be able to find some time to make progress on implementing the interrupt and isochronous type USB transfers.

I assume (some part) of the ST code implements everything you need. (Build one or more entire USB device which supports the transfer & endpoint types you want)

Edit: Without writing a host-side USB driver, the obstacle to using the transfer and endpoint types, in the way you want, is the host-side USB driver.
There is a limited set of device types supported, and the combination of transfer types (and endpoints), *and* the way they are used might not exist.

You may get some problems:
1. The amount of code you end up having to deal with is too huge, and it is unmanageable. Response: No big help here other than try to find the smallest example possible to get to grips with the code.
2. The compiler used for the code assumes there are specific libraries which are not available in source code.
Response: Nasty. Ask for help if this happens.
3. The ST code forces itself to be loaded at a specific address, which kills the Maple bootloader.
Response: Unpleasant but unlikely to be insoluble.
4. Other problems ... :-)
Response: ask for help, it may be hard work in places, but I would expect that nothing is insoluble except the ST code (which you combine to do what you want) needs much more Flash or RAM than is on the Maple, (or more endpoints than the USB hardware supports. Once the 8 USB endpoints, which is quite a lot, are allocated, there is no way to create more on the STM32F)

Edit: tried to clarify my words, some changes are in "(...)"

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC

I will respond to gbulmer's above post when I have time early next week.

If I was off the mark, save yourself time, and ignore it.

Posted 4 years ago #
mbolivar
LeafLabs

Fantastic discussion so far! This definitely seems like the makings of a tutorial on how to read the low-level libmaple code.

To gbulmer's excellent responses, I would add only this:

StephenFromNYC:

What is a register, and how are registers related to these questions? How are registers access (read or changed) by software?

If you read ST document RM0008 (http://www.st.com/stonline/products/literature/rm/13902.pdf ; it's the central reference manual for the entire Cortex M3 line of ST microcontrollers), you'll notice that the entire discussion for a given peripheral (like an ADC converter or the USB device) is explained in terms of "registers", and bits inside of those registers.

Registers in this sense are the "specific memory locations" gbulmer was referencing in this paragraph:

The program uses specific memory locations to put or get specific values, the electronics is 'directly connected' to specific locations and are triggered by values in those locations, and (the electronics) sets one or more bits within memory values to give back data.

I'm currently in the process of writing up a design document for libmaple (specifically, for the refactor branch that we keep talking about). An early draft is available here; it contains some more discussion on what registers are and how we interact with them in our source code:

http://static.leaflabs.com/mbolivar/libmaple_design/

Finally, as a parting shot, MIT has course materials for the class 6.004 available online:

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-004-computation-structures-spring-2009/

That's the class where undergraduates are taught the basics of how computers are organized at the hardware level. I found it to be extremely well taught and very illuminating, so if you decide you're interested in the low level details, I'd recommend looking at the link above.

Posted 4 years ago #
gbulmer
Moderator

mbolivar - thanks for the ocw.mit link

I did this sort of stuff 30+ years ago when I did my CS degree (though I thought the Osborne book was better) when we did 'computer architecture'. We hand-assembled programs, and programmed the hardware in hex, which I think was a bit harsh, but we understood the bare-metal basics.

I've read some of the Hennessy and Patterson books.
So now some more 'grist for the mill' :-)

I am looking forward to Oak. I hope easier FPGA programming will re-kindle people's interest in hardware-software interfaces, and givem them a practical way to experiment.

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

Thanks to mbolivar for the link to the MIT open courseware and for an early view to the libmaple design tutorial. I like the approach of starting with a simple description of how libmaple accesses the ADC functions. Now I have a better understanding of registers and how they are used on the Maple.

Last fall I downloaded the RM0008 reference manual (version 11), but I forgot about it because it was too early to appreciate its content. Version 12 is the most recent version of this document. It answers many of my questions.

I hope gbulmer's earlier answers to my questions can be applied by other users focusing on features of microcontrollers other than USB! Thanks for the references/resources.

I was not able to reply to gbulmer's insightful explanations during the weekend, but here are some more reflections on his comments.

gbulmer said:

The electronics of a USB peripheral, to the level of this discussion, implements the low-level behaviour directly. The circuits are organised irrevocably to implement a fixed set of functions. There is no code inside the USB peripheral that we can get at.

Yes, this makes perfect sense to me. I did a bad job of describing what I was imaging/speculating. The circuits inside any peripheral (eg. USB) implement a specific behavior which cannot be changed because the logic gates in the silicon cannot be changed. [Side question: are FPGAs, which will be used in the Maple Native, similar to reprogrammable RAM which does not lose the memory contents?]

Source "code" does not exist in any tangible way in a peripheral, but I am guessing that if all the logic gates of an extremely simple integrated circuit are described it is possible to create a flow diagram which matches what the silicon circuits accomplish. Once you have a flow diagram you understand how the circuit works. In a peripheral the only circuits present (hopefully) are those needed to accomplish a specific job.

gbulmer continues with:

The hardware is mapped into fixed memory locations (like variables at specific addresses), and specific bits within those memory locations interact with the underlying electronics.

Yes, I can easily imagine setting specific predefined physical memory locations (including memory locations in peripherals) to be equal to specific varibles. Is this similar to the old "poke" functions? After "activation" and some flipping of the logic gates the results can be read via a "peek" type function. I appreciate how the result (eg. a variable of type char) can be broken down into its individual bits (eg. a char has eight bits; each which can have a different meaning).

gbulmer continues with:

memory locations are part of peripherals, and are visible to the program.

The above quote makes sense.

I appreciate that function names used in libmaple do not have to be copied from the st.com code. It is the st.com code behavior which has to be emulated in libmaple, not the function names.

I appreciate that the st.com demo code (distributed for use on their evaluation boards) and the LeafLabs code are both on the same footing (neither is at a lower or higher level). All code occupies the FLASH/SRAM in the microcontroller. Do BIOS type programs exist in microcontroller? My guess is no.

Let me try to explain what I meant when I wrote:

When microprocessors are programmed are any variable names reserved?

If a reserved software variable name were equivalent to a physical memory location (which we have established can exist in a peripheral) it would be a way for programs to set memory spaces to specific values.

Now things get fuzzy for me really quickly.

How do the bits interact with the underlying electronics? Do examples of "underlying electronics" include the USB circuits? My assumption is yes.

After the required physical memory locations are set to the required values in a peripheral device how is a circuit activated/triggered?

In order to create cleaner core code for the USB functions how do programmers know the specific memory locations to place variables (the "where") and how to trigger the specified behavior (I thought about using the word "function" here, but that seems to suggest source code, which I know is *not* present) in a peripheral?

A simpler way to ask the same question is where is the st.com documentation (besides the code demos) which describes how to access/change/trigger/read the desired behaviors? Or does one simply need to read and fully understand what the st.com demo source code achieves before leaner libmaple quality code can be written?

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
x893
Member

Books and theoretical knowledge very perfect but what happend if i set crystal with 4 Mhz except 8Mhz. How many changes i need make for UART work at 57600. After 2 days porting Maple for STM32F105 the situation is very sad. ST library make more occuracy but more complex.
In my local copy of maple ~ 30% additional functions which not presents in maple (and i not see any plans about implement it).

I understand that 99% of maple professional customers never need this functions but beginners like me sometime need link timers or use CAN.

Posted 4 years ago #
mbolivar
LeafLabs
x893,

Books and theoretical knowledge very perfect but what happend if i set crystal with 4 Mhz except 8Mhz. How many changes i need make for UART work at 57600. After 2 days porting Maple for STM32F105 the situation is very sad. ST library make more occuracy but more complex.

You are correct. The current state of the libmaple master tree makes all sorts of assumptions about how you're using the microcontroller that are not appropriate for all situations. We are trying to make the low-level libmaple APIs make as few assumptions as possible about the particular chip you are using.

For example, here is a function in my personal libmaple clone that makes doing what you want with the USART much easier:
```
/**
 *  @brief Enable a USART in single buffer transmission mode, multibuffer
 *     receiver mode.
 *  @param dev USART to be initialized
 *  @param clock_speed Clock rate, in cycles per microsecond
 *  @param baud Baud rate to set
 */
void usart_init(usart_dev *dev, uint32 clock_speed, uint32 baud) {
    rcc_clk_enable(dev->clk_id);
    nvic_irq_enable(dev->irq_num);

    /* Initialize rx ring buffer  */
    rb_init(dev->rb, USART_RX_BUF_SIZE, dev->rx_buf);

    /* Set baud rate */
    usart_set_baud_rate(dev, clock_speed, baud);

    /* Enable the USART and set mode to 8n1 */
    dev->regs->CR1 = (USART_CR1_TE          |    // transmitter enable
                      USART_CR1_RE          |    // receiver enable
                      USART_CR1_RXNEIE);          // receive interrupt enable
    dev->regs->CR1 |= USART_CR1_UE;
}
```
In my local copy of maple ~ 30% additional functions which not presents in maple (and i not see any plans about implement it).

We'd love to see your patches. Are they available online somewhere?
Posted 4 years ago #
x893
Member

For example

gpio_remap.h

#ifndef _GPIO_REMAP_H
#define _GPIO_REMAP_H

#ifdef __cplusplus
extern "C" {
#endif

#define AFIO_MAPR2 ((volatile uint32*)0x4001001C)
#define DBGMCU_IDCODE ((volatile uint32*)0xE0042000)
#define DBGMCU_CR ((volatile uint32*)0xE0042004)

#define GPIO_Remap_SPI1 #define GPIO_Remap_I2C1 #define GPIO_Remap_USART1 #define GPIO_Remap_USART2 #define GPIO_PartialRemap_USART3 #define GPIO_FullRemap_USART3 #define GPIO_PartialRemap_TIM1 #define GPIO_FullRemap_TIM1 #define GPIO_PartialRemap1_TIM2 #define GPIO_PartialRemap2_TIM2 #define GPIO_FullRemap_TIM2 #define GPIO_PartialRemap_TIM3 #define GPIO_FullRemap_TIM3 #define GPIO_Remap_TIM4 #define GPIO_Remap1_CAN1 #define GPIO_Remap2_CAN1 #define GPIO_Remap_PD01 #define GPIO_Remap_TIM5CH4_LSI #define GPIO_Remap_ADC1_ETRGINJ #define GPIO_Remap_ADC1_ETRGREG #define GPIO_Remap_ADC2_ETRGINJ #define GPIO_Remap_ADC2_ETRGREG #define GPIO_Remap_ETH #define GPIO_Remap_CAN2 #define GPIO_Remap_SWJ_NoJTRST #define GPIO_Remap_SWJ_JTAGDisable #define GPIO_Remap_SWJ_Disable #define GPIO_Remap_SPI3 #define GPIO_Remap_TIM2ITR1_PTP_SOF #define GPIO_Remap_PTP_PPS ((uint32)0x00000001) /*!< SPI1 Alternate Function mapping */
((uint32)0x00000002) /*!< I2C1 Alternate Function mapping */
((uint32)0x00000004) /*!< USART1 Alternate Function mapping */
((uint32)0x00000008) /*!< USART2 Alternate Function mapping */
((uint32)0x00140010) /*!< USART3 Partial Alternate Function mapping */
((uint32)0x00140030) /*!< USART3 Full Alternate Function mapping */
((uint32)0x00160040) /*!< TIM1 Partial Alternate Function mapping */
((uint32)0x001600C0) /*!< TIM1 Full Alternate Function mapping */
((uint32)0x00180100) /*!< TIM2 Partial1 Alternate Function mapping */
((uint32)0x00180200) /*!< TIM2 Partial2 Alternate Function mapping */
((uint32)0x00180300) /*!< TIM2 Full Alternate Function mapping */
((uint32)0x001A0800) /*!< TIM3 Partial Alternate Function mapping */
((uint32)0x001A0C00) /*!< TIM3 Full Alternate Function mapping */
((uint32)0x00001000) /*!< TIM4 Alternate Function mapping */
((uint32)0x001D4000) /*!< CAN1 Alternate Function mapping */
((uint32)0x001D6000) /*!< CAN1 Alternate Function mapping */
((uint32)0x00008000) /*!< PD01 Alternate Function mapping */
((uint32)0x00200001) /*!< LSI connected to TIM5 Channel4 input capture for calibration */
((uint32)0x00200002) /*!< ADC1 External Trigger Injected Conversion remapping */
((uint32)0x00200004) /*!< ADC1 External Trigger Regular Conversion remapping */
((uint32)0x00200008) /*!< ADC2 External Trigger Injected Conversion remapping */
((uint32)0x00200010) /*!< ADC2 External Trigger Regular Conversion remapping */
((uint32)0x00200020) /*!< Ethernet remapping (only for Connectivity line devices) */
((uint32)0x00200040) /*!< CAN2 remapping (only for Connectivity line devices) */
((uint32)0x00300100) /*!< Full SWJ Enabled (JTAG-DP + SW-DP) but without JTRST */
((uint32)0x00300200) /*!< JTAG-DP Disabled and SW-DP Enabled */
((uint32)0x00300400) /*!< Full SWJ Disabled (JTAG-DP + SW-DP) */
((uint32)0x00201000) /*!< SPI3/I2S3 Alternate Function mapping (only for Connectivity line devices) */
((uint32)0x00202000) /*!< Ethernet PTP output or USB OTG SOF (Start of Frame) connected
to TIM2 Internal Trigger 1 for calibration
(only for Connectivity line devices) */
((uint32)0x00204000) /*!< Ethernet MAC PPS_PTS output on PB05 (only for Connectivity line devices) */

#define GPIO_Remap_TIM15 ((uint32)0x80000001) /*!< TIM15 Alternate Function mapping (only for Value line devices) */
#define GPIO_Remap_TIM16 ((uint32)0x80000002) /*!< TIM16 Alternate Function mapping (only for Value line devices) */
#define GPIO_Remap_TIM17 ((uint32)0x80000004) /*!< TIM17 Alternate Function mapping (only for Value line devices) */
#define GPIO_Remap_CEC ((uint32)0x80000008) /*!< CEC Alternate Function mapping (only for Value line devices) */
#define GPIO_Remap_TIM1_DMA ((uint32)0x80000010) /*!< TIM1 DMA requests mapping (only for Value line devices) */

#define GPIO_Remap_TIM9 ((uint32)0x80000020) /*!< TIM9 Alternate Function mapping (only for XL-density devices) */
#define GPIO_Remap_TIM10 ((uint32)0x80000040) /*!< TIM10 Alternate Function mapping (only for XL-density devices) */
#define GPIO_Remap_TIM11 ((uint32)0x80000080) /*!< TIM11 Alternate Function mapping (only for XL-density devices) */
#define GPIO_Remap_TIM13 ((uint32)0x80000100) /*!< TIM13 Alternate Function mapping (only for XL-density devices) */
#define GPIO_Remap_TIM14 ((uint32)0x80000200) /*!< TIM14 Alternate Function mapping (only for XL-density devices) */
#define GPIO_Remap_FSMC_NADV ((uint32)0x80000400) /*!< FSMC_NADV Alternate Function mapping (only for XL-density devices) */

void gpio_remap(uint32 GPIO_Remap, uint8 NewState);
uint32 DBGMCU_GetREVID(void);
uint32 DBGMCU_GetDEVID(void);

#ifdef __cplusplus
} // extern "C"
#endif

#endif

and gpio_remap.c

#include "libmaple.h"
#include "gpio.h"
#include "gpio_remap.h"
#include "util.h"

#define LSB_MASK ((uint16)0xFFFF)
#define DBGAFR_POSITION_MASK ((uint32)0x000F0000)
#define DBGAFR_LOCATION_MASK ((uint32)0x00200000)
#define DBGAFR_NUMBITS_MASK ((uint32)0x00100000)
#define DBGAFR_SWJCFG_MASK ((uint32)0xF0FFFFFF)

#define IDCODE_DEVID_Mask ((uint32)0x00000FFF)

void gpio_remap(uint32 GPIO_Remap, uint8 NewState)
{
uint32 tmp = 0x00, tmp1 = 0x00, tmpmask = 0x00, tmpreg;

if((GPIO_Remap & 0x80000000) == 0x80000000)
tmpreg = *(AFIO_MAPR2);
else
tmpreg = *(AFIO_MAPR);

tmpmask = (GPIO_Remap & DBGAFR_POSITION_MASK) >> 0x10;
tmp = GPIO_Remap & LSB_MASK;

if ((GPIO_Remap & (DBGAFR_LOCATION_MASK | DBGAFR_NUMBITS_MASK)) == (DBGAFR_LOCATION_MASK | DBGAFR_NUMBITS_MASK))
{
tmpreg &= DBGAFR_SWJCFG_MASK;
*(AFIO_MAPR) &= DBGAFR_SWJCFG_MASK;
}
else if ((GPIO_Remap & DBGAFR_NUMBITS_MASK) == DBGAFR_NUMBITS_MASK)
{
tmp1 = ((uint32)0x03) << tmpmask;
tmpreg &= ~tmp1;
tmpreg |= ~DBGAFR_SWJCFG_MASK;
}
else
{
tmpreg &= ~(tmp << ((GPIO_Remap >> 0x15)*0x10));
tmpreg |= ~DBGAFR_SWJCFG_MASK;
}

if (NewState != 0)
tmpreg |= (tmp << ((GPIO_Remap >> 0x15)*0x10));

if((GPIO_Remap & 0x80000000) == 0x80000000)
*(AFIO_MAPR2) = tmpreg;
else
*(AFIO_MAPR) = tmpreg;
}

/*
This field indicates the revision of the device:
In low-density devices:
– 0x1000 = Revision A
In medium-density devices:
– 0x0000 = Revision A
– 0x2000 = Revision B
– 0x2001 = Revision Z
– 0x2003 = Revision Y
In high-density devices:
– 0x1000 = Revision A
– 0x1001 = Revision Z
– 0x1003 = Revision Y
In XL-density devices:
– 0x1000 = Revision A
In connectivity line devices:
– 0x1000 = Revision A
– 0x1001 = Revision Z
*/
uint32 DBGMCU_GetREVID(void)
{
return (*((volatile uint32*)0x8000000));
// return((*(DBGMCU_IDCODE)) >> 16);
}

/*
This field indicates the device ID.
0x412 low-density devices
0x410 medium-density devices
0x414 high-density devices
0x430 XL-density devices
0x418 connectivity devices
*/
uint32 DBGMCU_GetDEVID(void)
{
return(*DBGMCU_IDCODE & IDCODE_DEVID_Mask);
}

Posted 4 years ago #
gbulmer
Moderator

StephenFromNYC - I think this covers all the remaining questions, if not, keep going :-)

How do the bits interact with the underlying electronics? Do examples of "underlying electronics" include the USB circuits? My assumption is yes.

Yes USB is part of the underlying electronics.

After the required physical memory locations are set to the required values in a peripheral device how is a circuit activated/triggered?

It depends in which peripheral and which register values are being set.

Remember the whole STM32F is clocked at a few speeds, the main processor and some peripherals at 72MHz, and some of the other peripherals are at 36MHz. Some peripherals divide down the clock to get their working clock. This is described in RM0008. Many of the peripherals need to be enabled, which effectively switches them on, and connects them to an appropriate clock signal.

The memory locations 'built into' peripherals are running synchronously. Many of the peripherals will trigger behaviour on the next clock signal. Some will allow values to be set, but will not act until specifically enabled (I vaguely remember some of the timer features work this way). Again RM0008 (and errata) describes the precise details.

In order to create cleaner core code for the USB functions how do programmers know the specific memory locations to place variables (the "where") and how to trigger the specified behavior (I thought about using the word "function" here, but that seems to suggest source code, which I know is *not* present) in a peripheral?

As mbolivar said RM0008 describes the peripherals and their registers.

A simpler way to ask the same question is where is the st.com documentation (besides the code demos) which describes how to access/change/trigger/read the desired behaviors? Or does one simply need to read and fully understand what the st.com demo source code achieves before leaner libmaple quality code can be written?

there are a couple of USB documents at ST.com at User Manuals

For example http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD00158241.pdf
which is called UM0424 User manual: STM32F10xxx USB-FS-Device development kit

It gives an overview for each of the USB devices demo'd in the source at http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&SubClassID=1169

Posted 4 years ago #
StephenFromNYC
Moderator

Hello-

gbulmer, thanks again for all the help and encouragement. I may revive the USB specific discussion after I do some more reading.

I have not looked for RM0008 errata on the st.com web site. Where are these error reports stored (or found) and how are their titles described?

Yes, I have the UM0424 user manual (a PDF) for the full speed development kit (a zip). Posting the complete URL for UM0424 will be useful to some users.

The development kit manual and the peripheral demonstration software (designed to be run on the st.com evaluation boards) are also listed on the (non flash and faster loading?) st.com link I provided earlier for the three st.com pages which describe the three different STM32F103 microcontrollers used on the Maple, Maple Mini, and Maple Native boards.

During the next few weeks I may try to implement the st.com USB demonstration programs (released to work with their evaluation board). I am curious to see if I can make any headway on the isochronous USB transfers.

Yes, from an earlier 2010 post I remember a warning about processor clock speed and STM32 features, such as ADC sampling rates. My next big block of time working with the Maple will wait until I see the new DMA stuff which comes out with the next IDE.

Thanks!

Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

Posted 4 years ago #
x893
Member

Also i remove next files:
usb_type.h
usb_hardware.c
usb_hardware.h
also modify print.cpp so not use scanf()

Posted 4 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.