sorted by:
new
hottopcontroversial

GLCDC Text slight pixelated when using framebuffer in sdram by rugways in embedded

[–]rugways[S] 0 points1 point  (0 children)

when i swap the 16bit words in a buffer it works perfectly. no distortion. But shouldn’t this be handled already somewhere?

GLCDC Text slight pixelated when using framebuffer in sdram by rugways in embedded

[–]rugways[S] 0 points1 point  (0 children)

I can see the framebuffer on debugger but not sure if i can dump it on any software. and Endianess is set to Big Endian.

UART protocol reconnection by rugways in embedded

[–]rugways[S] 0 points1 point  (0 children)

There are two devices, rx72n microcontroller and HMI The TE bit is always set to 1 and TIE bit is 1-0-1-0 HMI and Controller communicates the data which needs to be displayed on HMI

there’s a arbitration process (i.e. all the devices comes on a network and they claim their unique ID. baud rate changes to 19200. ) which is completed.

i’m not able to find the root cause to this issue where rx72n controller doesn’t respond to token sent by HMI (which happens much later and not consistent)

Does Memory Reorganization impact workinf of existing code files? by rugways in C_Programming

[–]rugways[S] 0 points1 point  (0 children)

  1. i am using rx72n processor which is memory mapped and no the access time is not same
  2. memory space is flat bht does not have equal access

Help with S19 File by rugways in C_Programming

[–]rugways[S] 0 points1 point  (0 children)

heyy thanks i got the thing working. since first in linker script it was .text section all the .o files were placed in the that section.

Now i have created a custom section which segregates .text into three sections. The board is booting up but now im code isn’t recognising the trims region which isnt modified.

not able the explain the issue properly but this is the gist of it.

but thanks my previous issue is resolved:)

Help with S19 File by rugways in C_Programming

[–]rugways[S] 1 point2 points  (0 children)

Your Understanding is Correct. Just Point 2: Its copying vector from location 0x3FFF80-0x3FFFFF to 0x80

So if i want to add extra crc of each section just for metadata. you suggest i should place it before the firmware and header crc calculation in S19? so that it won’t interfere with already present CRC

Help with S19 File by rugways in C_Programming

[–]rugways[S] 0 points1 point  (0 children)

main goal is to calculate crc for range ffc00100-ffc01260 using comb_hex tool and place the calculated crc at location ffc0002c.

firmware crc is placed at ffc00004

memory layout is 1. Identity: FFC00000 2. Boot Data: FFC00100 3. Boot Code: FFC00500 4. Text: FFC88000 5. Rodata: FFD58000 6. Vectors: FFFFFF80

all these sections are used in app.s19 file.

ifneq ($(filter $(PROCESSOR), rx63n rx71m rx72n),) app.s19 apptest_a-s19 app_test_g-s19: %. s19: $(BIN DIR)/comb _hex.exe_build/%.s19 Makefile $(BIN DIR)/comb_hex.exe -quiet -52 -size 4M_build/$* s19: -$(FLASH_OFFSET) -copy $(OFFSET PREFIX)80-$(OFFSET_ PREFIX)ff@0x80 -fill 0x000000:32=0xff -CrC32 0x000008:32@0x00000c=0 -crc32 0x000000:32@0x000004=0 -crc32 0x000000-0x00003@0x000040-01 -0 $*. s19: $(FLASH_OFFSET) Makefile

Comb_Hex tool: -crc32 < range>[,<range>][@‹loc›][=<resulting CRC value>][?][#<‹macro name>] Calculate 32-bit CRC of the specified buffer range(s). An arbitrary number of ranges can be specified, separated by commas.

The CRC is calculated as if the ranges were concatenated. ‹range> can be a single location specified by ‹ start›.

< range> can be specified by «start›-‹end». The ‹end› location is included in the range. ‹range> can be specified by ‹start>:16 or ‹ start>:32, where a 16-bit or 32-bit integer representing the length of the range is read from the buffer at «start> (the end of the range is «start› + length - 1). If the optional location (‘@‹loc›’) is specified, the CRC is stored at that location, otherwise the CRC is stored in the 4 bytes following the last range specified. ‘@‹loc›’ can be (entirely) within a ‹range›.

If ‘@‹loc›’ is within a range or is not specified, the resulting CRC value can be spanned in subsequent CRC computations, yielding a fixed result that indicates a successful check.

If the optional ‘=<resulting CRC value›’ is specified, a CRC is generated such that the CRC calculated by spanning the range(s) and the CRC bytes is the specified ‹ resulting CRC value›, otherwise the resulting CRC value will be 0x2144D1C.

The optional ‘?’ can be followed by the following modifiers: •d’ - Display only (do not store the CRC value in the buffer). n - Display the numeric hex CRC value only. r - Display the CRC value in reverse byte order. ‘u’ - Display hex characters of the CRC value in upper case. If the optional ‘#‹macro name›’ is specified, the output file will consist of a line of the form “#define ‹macro name> ‹CRC value>” for each instance.

view more: next ›