Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • FPC Source FPC Source
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,278
    • Issues 1,278
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 59
    • Merge requests 59
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • FPC
  • FPCFPC
  • FPC SourceFPC Source
  • Issues
  • #39739
Closed
Open
Issue created May 27, 2022 by kupferstecher@kupferstecher

RISC-V riscv32 embedded - Stack address

The issue occurs on a risc-v 32bit microcontroller, namely the CH32V307 from WCH, that I currently try to add to fpc.

The stack address is defined in the linker script providing a symbol. The linker script is generated in the file compiler/systems/t_embed.pas with the following line:

Add('_stack_top = 0x' + IntToHex(srambase+sramsize-1,4) + ';');

The programm crashes with a hard fault in the moment the stack is used the first time. As far as I understand the microcontroller only allows 32bit alligned memory access. It worked after changing the line to:

Add('_stack_top = 0x' + IntToHex(srambase+sramsize-4,4) + ';');

But I'm not sure what is the best way to fulfill this without breaking existing code. In t_embed.pas it could be distinguished between each controller, but that would perspectively blow up the file. The offset could also be adjusted in the controllers startup code, where the stack pointer is initialized. But then it would differ from the original startup code making future porting of other devices more difficult. Or it could be changed to -4 for all devices, perhaps it doesn't break any compatibility, but just wastes 3 byte for devices that would support byte allignment? Or is the -1 even wrong, as a a 32bit access (riscv32) to (srambase+sramsize-1) would result in an access including the 3 bytes outside of the defined SRAM region?

Edited May 27, 2022 by kupferstecher
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking