trying to build using IAR a sample of module and module_manager on STM32-H7 starting from the sample provided in "threadx-6.1.5_rel" and from https://learn.microsoft.com/en-us/azure/rtos/threadx-modules/chapter3 i keep getting called the "module_fault_handler()" it seems because of memory error after calling txm_module_manager_start().
In the provided examples during module_manage initializations i see:
txm_module_manager_initialize((VOID *) 0x90000000, 0xE000);
txm_module_manager_external_memory_enable(&my_module, (void *) 0x90000000, 128, TXM_MODULE_MANAGER_SHARED_ATTRIBUTE_WRITE);
Is not clear to me from where the hard coded values comes and/or how they are calculated, seeing the file sample_threadx_module.icf i couldn't figure out this.
Thank you in advance
The hardcoded values are just an example. Please provide memory locations that are compatible with your memory map.
Related
CUDA 12 indicates that these two functions:
CUresult cuModuleGetSurfRef (CUsurfref* pSurfRef, CUmodule hmod, const char* name);
CUresult cuModuleGetTexRef (CUtexref* pTexRef, CUmodule hmod, const char* name);
which obtain a reference to surface or a texture, respectively, from a loaded module - are deprecated.
What are they deprecated in favor of? Are surfaces and textures in modules to be accessed differently? Will they be entirely out of modules? If it's the latter, how would one work with them using the CUDA driver API?
So, based on #talonmies' comment, it seems the "replacement" are "texture objects" and "surface objects". The main difference - as far as is evident in the API - is that the new "objects" have less API calls, which take richer descriptors. Thus, the user sets fields themselves, and does not need the large number of cuTexRefGetXXXX and cuTexRefSetXXXX calls. There are also "tensor map objects", appearing with Compute Capability 9.0 and later.
I am having trouble correctly declaring a pointer in the IAR Embedded Workbench to access external RAM connected on the EMI port of an CC8051F121.
Any example code or pointer to example would be appreciated
Thank You
Regards
See IAR's support article on 8051 programming.
So a pointer to an int in xdata would be like:
int __xdata *myptr;
The attribute ensures only MOVX instructions are emitted in assembly, as required by the C8051F121 datasheet.
See also this app note.
I'm trying to add an new device in the qemu.
In the respective cpu file, used sysbus_mmio_map to set the base address.
sysbus_mmio_map(SYS_BUS_DEVICE(&s->brif), 0, BASE_ADDRESS);
In the newly created device file,
memory_region_init_io(&s->iomem, obj, &ops, s, "brif", SIZE);
sysbus_init_mmio((SYS_BUS_DEVICE(obj), &s->iomem);
The ops has the corresponding read and write handlers.
My read handler is getting called when I access the IO memory region using gdb, but my write handler is not getting called when I write to the IO memory region using gdb.
What am I missing?
Update: I do get the write handlers if I write to the IO memory region from the code running inside the guest, the problem is only when I try to access from the gdb.
I belive it's just a bug. Se this bugreport (with a patch included).
Are there corresponding functions for cudpp.h in cuda.h for the following:
CUDPPHandle theCudpp;
cudppCreate(&theCudpp);
CUDPPConfiguration config;
config.op = CUDPP_ADD;
config.datatype = CUDPP_FLOAT;
config.algorithm = CUDPP_SCAN;
config.options = CUDPP_OPTION_FORWARD | CUDPP_OPTION_EXCLUSIVE;
CUDPPHandle scanplan = 0;
CUDPPResult res = cudppPlan(theCudpp, &scanplan, config, numElements, 1, 0);
It is hard to help you, if you neither explain the exact problem you have, nor post any code. Please read How to Ask for Programming Help?.
But to answer the first part of your question: cuda.h is the main header file for CUDA. cudpp.h is the main header file for CUDPP, which is a library built on top of CUDA. They are entirely different things. Explaining what the difference is, is like explaining the difference between apples and chairs.
Judging from your question and your comment, you do not understand the very basics necessary to use either. You have not even properly embedded the library (its header, library and binary files) into your project. You probably have also not resolved it's dependencies (for example, you also need thrust for CUDPP 2.0+). You will have to look in the CUDPP documentation for that information. If they do not provide that, you have to check how to add external libraries to the tool-chain you use (we don't even know if you use GCC, MSVC, CLANG or what-have-you).
Good luck.
I have a nice fully functioning module (wrtten using tcl/cpp) it works fine.
I want to use ramdebugger to debug scripts using that module
When I enter
load mylib.so
command1_from_lib xx
command2_from lib yy
If (say) command2 returns an error then ramdebugger dies
[paul#paul-es5 ramdebugger7.7.1]$ ./ramdebugger
alloc: invalid block: 0x999c058: 0 0
Aborted
It dies here in libtcl / ResetObjResult
if ((objResultPtr->bytes != NULL)
&& (objResultPtr->bytes != tclEmptyStringRep)) {
ckfree((char *) objResultPtr->bytes);
}
My suspicion is there is confusion over the global tclEmptyStringRep. I think the starkitted(?) ramdebugger has one and the dynamically loaded libtcl has a different one - the bytes pointer should logically be pointing to an empty string but the value there does not match what gdb shows for the global
I am a tcl noob and need any help I can get. Alternatively a suggestion for a different debugger would work
edit: fixed
Use tclStub to defer the link between the extension and the tcl runtime.
This sounds very much like a bug to me, as opposed to a question which this site can answer. You should contact the ramdebugger people to see if they can help.
However, for general Tcl debugging you could also see if the tools produced by ActiveState help; IIRC you can get a free trial to see if they can make any headway. (Myself, I'm of the put-lots-of-printf-calls in school of debugging, so I'm nobody's poster child.)